request recommendation for api record / playback software
-
i have searched w/o success for software which outputs trace/logging info for each api call and which then permits playback . may i please inquire of any recommendations . thank you kindly [EDIT] perhaps i should make clear the api to which i refer is my own i.e. not of OS . e.g. if a user calls my api and finds error he/she should be able to attempt repro w/ logging/tracing switched on in my library so i can then investigate upon playback .
It depends what your use case is. If you just want to intercept some API calls and play back to do some local testing, if they are HTTP/HTTPs based, you could always use Postman.
-
i have searched w/o success for software which outputs trace/logging info for each api call and which then permits playback . may i please inquire of any recommendations . thank you kindly [EDIT] perhaps i should make clear the api to which i refer is my own i.e. not of OS . e.g. if a user calls my api and finds error he/she should be able to attempt repro w/ logging/tracing switched on in my library so i can then investigate upon playback .
Are you on the server side or client side? My latest experience with requesting/consuming data from a restful api has been dreadful. X| If you are the provider, it's a pretty simple task to read your webserver logs into a gridview or something for analysis/playback. I know you probably don't want to roll your own, but it does have some real advantages.
"Go forth into the source" - Neal Morse "Hope is contagious"
-
Are you on the server side or client side? My latest experience with requesting/consuming data from a restful api has been dreadful. X| If you are the provider, it's a pretty simple task to read your webserver logs into a gridview or something for analysis/playback. I know you probably don't want to roll your own, but it does have some real advantages.
"Go forth into the source" - Neal Morse "Hope is contagious"
thank you for your kind reply . i know nothing re/ servers or clients or restful's . my library/application has nothing to do w/ websites as i know nothing about internet programming . it is a simple interface to local permanent storage . it seems to my surprise an api-record/playback software does not exist . i am quite willing even happy to write my own as it does not seem particularly difficult and i expect i would find pleasure in its successful implementation . i still do not understand why such does not exist as it seems a useful tool which means a profitable tool which means thousands of superior programmers would have written such prior . -Best
-
Are you on the server side or client side? My latest experience with requesting/consuming data from a restful api has been dreadful. X| If you are the provider, it's a pretty simple task to read your webserver logs into a gridview or something for analysis/playback. I know you probably don't want to roll your own, but it does have some real advantages.
"Go forth into the source" - Neal Morse "Hope is contagious"
I apologise for my previous grumpy reply. Like most folks above I assumed that your question was about a REST-API and... For your, now clarified, case I dunno about playback, but for recording: you can capture system calls. I.e intercept calls between your app and the system libraries (.DLLs / .SOs). * Windows: apimonitor (GUI application) * Linux:
strace(command-line) But... That is approach probably over the top if you only care about file-system events. For file system events there is * .NET library:FileSystemWatcher* Linux commandline:iwatch* Cross Platform, build from C++: GitHub - emcrisostomo/fswatch[^]"If we don't change direction, we'll end up where we're going"
-
i have searched w/o success for software which outputs trace/logging info for each api call and which then permits playback . may i please inquire of any recommendations . thank you kindly [EDIT] perhaps i should make clear the api to which i refer is my own i.e. not of OS . e.g. if a user calls my api and finds error he/she should be able to attempt repro w/ logging/tracing switched on in my library so i can then investigate upon playback .
I apologise for my previous grumpy reply. Like most folks above I assumed that your question was about a REST-API and... For your, now clarified, case I dunno about playback, but for recording: you can capture system calls. I.e intercept calls between your app and the system libraries (.DLLs / .SOs). * Windows: apimonitor (GUI application) * Linux:
strace(command-line) But... That is approach probably over the top if you only care about file-system events. For file system events there is * .NET library:FileSystemWatcher* Linux commandline:iwatch* Cross Platform, build from C++: GitHub - emcrisostomo/fswatch[^]"If we don't change direction, we'll end up where we're going"
-
i have searched w/o success for software which outputs trace/logging info for each api call and which then permits playback . may i please inquire of any recommendations . thank you kindly [EDIT] perhaps i should make clear the api to which i refer is my own i.e. not of OS . e.g. if a user calls my api and finds error he/she should be able to attempt repro w/ logging/tracing switched on in my library so i can then investigate upon playback .
Sounds like you need "HTTP Toolkit" [https://httptoolkit.com/\](https://httptoolkit.com/) Iv'e used this many, many times for live debugging over the years. All the user needs to do is install it, then run it, they use an appropriate interception mode, to run the app with your lib in, under control of the toolkit, the free version is more than enough for standard debugging, but if you need to export the data you will need to pay for a subscription. HTTP toolkit can even "live proxy" calls made on a mobile device such as an android phone, over your local lan via wifi and/or usb direct into the PC running HTTP Toolkit, it's really quite scary what you can do with it, I've watched (and seen in plain text) things like my MS and Google account passwords being revealed to me when set up properly. If your feeling brave, and really understand HTTP and general networking, then Wireshark will do everything you need. It's not easy to set WS up to decrypt HTTPS however, but it can be done, and the results can be un-encrypted. WS will unfortunately record EVERYTHING network related going on in the target machine however, so you will need to learn to use a lot of filtering. Telerik fiddler is another tool you may wish to look at, but the new versions are no where near as good as the old "Version 4 classic version". If you can get "Fiddler Classic" then you have a great tool, which is easy to set up for un-encrypting https in real time (One button click) and will allow you to sniff, record and even edit and play back requests. Shawty
-
thank you for your kind reply . i know nothing re/ servers or clients or restful's . my library/application has nothing to do w/ websites as i know nothing about internet programming . it is a simple interface to local permanent storage . it seems to my surprise an api-record/playback software does not exist . i am quite willing even happy to write my own as it does not seem particularly difficult and i expect i would find pleasure in its successful implementation . i still do not understand why such does not exist as it seems a useful tool which means a profitable tool which means thousands of superior programmers would have written such prior . -Best
BernardIE5317 wrote:
my library/application has nothing to do w/ websites as i know nothing about internet programming . it is a simple interface to local permanent storage . it seems to my surprise an api-record/playback
Ah...
BernardIE5317 wrote:
i still do not understand why such does not exist
Because it is not as easy as you think. An application that uses libraries is making a call that is controlled by the programming language, compiler and even the OS. At the most basic level you must do code injection just to interpret the call. This is how debuggers work. However you also want the values that are being passed in to the call. So you can do a 'playback'. Values are passed by the stack however knowing that does not help much with playback because values are often pointers. So you would need to retrieve what is being pointed at. But how do you know what is being pointed at so you can correctly walk that value to retrieve it? In general there is no way to know where a pointer ends without knowing what it is. And that becomes even worse if the object (space) being pointed to itself contains pointers. Debuggers do this because there is debug information stored (somewhere) that allows them to interpret that data - often dynamically as a user drills down on it. Further there is another very serious problem. Some values that are passed are not designed to be read twice. For example lazy loaded collections. Even if you managed to reset such a collection after reading it, it is even possible that the api call then might get different values (for example if the collection pulls from a database.)
-
BernardIE5317 wrote:
my library/application has nothing to do w/ websites as i know nothing about internet programming . it is a simple interface to local permanent storage . it seems to my surprise an api-record/playback
Ah...
BernardIE5317 wrote:
i still do not understand why such does not exist
Because it is not as easy as you think. An application that uses libraries is making a call that is controlled by the programming language, compiler and even the OS. At the most basic level you must do code injection just to interpret the call. This is how debuggers work. However you also want the values that are being passed in to the call. So you can do a 'playback'. Values are passed by the stack however knowing that does not help much with playback because values are often pointers. So you would need to retrieve what is being pointed at. But how do you know what is being pointed at so you can correctly walk that value to retrieve it? In general there is no way to know where a pointer ends without knowing what it is. And that becomes even worse if the object (space) being pointed to itself contains pointers. Debuggers do this because there is debug information stored (somewhere) that allows them to interpret that data - often dynamically as a user drills down on it. Further there is another very serious problem. Some values that are passed are not designed to be read twice. For example lazy loaded collections. Even if you managed to reset such a collection after reading it, it is even possible that the api call then might get different values (for example if the collection pulls from a database.)
thank you for your informative reply . i envision it as follows . utilizing presumably Clang to parse the source file which i know little of which would deduce argument types then inject logging code into the source code at top of each function also into each class passed as arguments so such can log themselves also in similar fashion pointer targets can be logged again as Clang deduces types . as for lazy loading i have no idea what that is but i am sure my simple library does not utilize it . - Best
-
thank you for your informative reply . i envision it as follows . utilizing presumably Clang to parse the source file which i know little of which would deduce argument types then inject logging code into the source code at top of each function also into each class passed as arguments so such can log themselves also in similar fashion pointer targets can be logged again as Clang deduces types . as for lazy loading i have no idea what that is but i am sure my simple library does not utilize it . - Best
-
If if the method is passed a void pointer (anonymous class pointer) what are you going to do with that? Especially for playback?
thank you for bringing this to my attention . a cursory examination of the ast dump by clang of a simple such example i.e. casting a void* to a class ptr and writing to a class member seems to reveal sufficient information to deduce the final values accessed via the newly cast ptr if given all other input values via run log/trace. -Best