Extend Recording feature: record all requests and responses for all endpoints #1603

djazz90 · 2024-11-22T12:35:04Z

djazz90
Nov 22, 2024

Hi everyone,

As a user of the application I'd like to have all the responses and requests recorded in proxy mode so that the third party API mocking becomes easier, development time and repetitive tasks become less, long and error prone copy-pasting work can be avoided.

Currently we can achieve this only by manually creating new responses, search for the original request and response pairs in the logs of the application and copy-paste them one by one into the our mock server's endpoint and create a manual rule for each.

Of course these are just my ideas, feel free to comment or correct me on things, this is just how I envisioned the feature in my head at first. I've attached an example picture showing some of the new things in red.

Initial implementation ideas:

This could be done by creating a new record button or by extending the current record button's functionality.
Create a new state for responses (for example: recorded or generated) which makes the newly recorded responses disabled.
- The status could be shown in the responses drop-down on the routes view (example picture)
The new responses could be generated as disabled by default
- Hence most likely there is work to do with these freshly created responses
- Would be good if we could toggle this in the global application settings
- Disabling them one-by-one would be a good thing too in the particular response's settings
The original request should be shown on the routes tab in the response's view as a new tab (example picture) to make the generated response's rule creation easier
Newly added responses should be added after the last response
- To maintain the order how the responses came in
The generated responses can be able to be deleted with one click for easy recreation
- Have a new icon somewhere to delete all recorded responses for a given mock server
- Need user confirmation to prevent accidental missclicks

Other thoughts, ideas.
This could be another feature on its own building onto the feature above. We can split these of course if you like the ideas.

Please note that I mainly considered XML and SOAP technologies here because that is what I'm working with at the moment.
This could be extended to apply to RESTful web services and even request parameters as well.

Create "request body hooks", these body hooks would be assigned for a specific path inside the requests
Simple hooks could be created to bound on some element's values. These values could be stored like, if a part of the body exactly matches the value in the request, then the corresponding response would be replied with
For successful body hooks the responses could be created as enabled
For successful body hooks the generated responses' name could be the hooked value
Example: we have a SOAP request where we hook the name element's value of the request
- We know the name element will be appearing in every request
- So we hook the element's value for the XML and store its value
- We create an automatic rule for the name itself when it equals the name element's value we respond with the particular response that we recorded
- For this mechanism of course would need prior knowledge of the API
Some re-recording logic could be done like not to re-record something that has already been recorded. (This also could be another feature on its own.)

255kb · 2024-11-26T10:12:18Z

255kb
Nov 26, 2024
Maintainer

There are a lot of ideas in this post. I will try to address them and identify the areas of improvements.

On the first part of your post:

I don't think we need a new status for recorded responses as this is equivalent to the existing default response (blue flag).
Let's consider this setup:

Without any rule, the first response being the default one (blue flag), the 3 others are de facto "inactive". They won't be served, ever.
During recording, the first response would be automatically the default one, and all the responses recorded after would stay in the order they were recorded. So, I don't think there is a need for any of the new mecanisms you describe (disabled status, "original" response, etc).

The only part I could eventually agree with is the following:

The generated responses can be able to be deleted with one click for easy recreation
Have a new icon somewhere to delete all recorded responses for a given mock server
Need user confirmation to prevent accidental missclicks

But I also think this sounds like deleting a route with all its responses. There is already a way to delete a response, but I don't think bulk responses deletion is that needed (but I may be mistaken). I would rather work first on route's bulk operations. Anyway, this could be a QoL improvement that is not related to recording in particular.

The main question remains: should we modify the recording feature so it records more than one response per route, and if yes, what would be the conditions? A different body is detected? A different query param is detected? Different headers?
This change could be interesting. It has also multiple benefits: it's the actual thing missing in what you describe. It's also a "small" change and an improvement that doesn't mandate a major release. I suggest you open an issue to track this specific change, if you agree, to see if it gathers some interest.

On the second part:

One remark first:

Please note that I mainly considered XML and SOAP technologies here because that is what I'm working with at the moment.
This could be extended to apply to RESTful web services and even request parameters as well.

Keep in mind that Mockoon is focusing on REST. So, most developments should target this first.

Regarding the hooks thing, I'm not sure I follow completely and I would probably need a concrete example to better understand. But for me, it seems to be the same as fetching the SOAP body properties with the body or bodyRaw helpers (as XML is supported), eventually storing it in a global variable (with setGlobalVar) and reusing it in a response. But I may be missing something.

Concerning the last part about "re-recording", I think we would need such feature first (for now we only have recording), before choosing the conditions of a re-recording. But I'm not sure re-recording is that needed for now. At least it's the first time I hear about it. My plan is to extend the Admin API to be able to record and remove routes during runtime. Re-recording would rather be two steps: deleting routes + recording.

1 reply

djazz90 Dec 3, 2024
Author

Thank you very much for replying!

As the first part, I agree with your reasoning on the new status. It looks unnecessary, thanks for pointing it out!

It could be enough to just delete the route and all its responses. With the QoL change bulk route deletion, deleting every recorded response would be easy. (There's maybe an edge-case where the status and the bulk response deletion could be needed. For example a given route has responses that are recorded and have responses that are just made by hand. In that case bulk response deletion for recorded responses would be a good option.)

As a new mechanism I did not say "original response". I've mentioned "original request", I mean the request which was originally sent that resulted the response which was recorded. I think displaying this original request (in a read-only text box on a new tab for example) for a recorded response is very handy for easy rule creation. For example a POST request with a body can hold valuable information for the rules if the user wants to create body related rules (that was my use case).
This also could be a list if multiple requests resulted the same response.
It would be good to have every information available on this tab, like request body, headers and URL it was posted to (that can also help if the user wants to create rules according to that data).

About the conditions:

Very good questions!
Yes, the current recording functionality should be extended by recording more than one response for a route.
As for each route:

I think the best is to have new responses recorded if the response body is different from those that are already recorded.
If we see a response that already been added, then add the request to the list of original requests.
- This idea can be improved later by adding rules based on query parameters, similarly to Create route from proxy request should add rule for query param #723
  - I can elaborate, but this is out of scope now I think.

I'm not confident in creating the issue until we aggree on things on the "original request" part and the conditions.
But I can create the issue though then I modify it until we both aggree on everything, if its good for you.
What do you think?

About the second part:

These body hooks purpose would be automatic rule creation. Having prior knowledge of the API we would be able to create these body hooks.

For example we have an proxied endpoint for search with a "/search" path.
We know it accepts a JSON like this:

{
  "searchString": "hi"
}

We'd create a request body hook which checks on the value of the request's JSON field searchString.
We would do a POST request with the example JSON body on the endpoint during recording.
This would result in a new response with a new rule of the hooked value, a JSON path for example where we have a JSON path expression "$.searchString" equals "hi"
Repeated calls to this endpoint would check if the rule was already added (assuming it has the same response as result)
- If it is an already existing value then we discard it.
- If it is a new value then we add a new rule to the previous rules like in point 5, but we separate them with an OR condition.
  - So following the last example we'd have a new request body like this:
```
{
  "searchString": "hello"
}
```
  - After this request being sent, we realize that it is a new value, we add it to the rules: a new JSON path expression "$.searchString" equals "hello".
  - Then we'll separate it with an OR condition to make sure this response will be served when called with "searchString" "hello" or "hi".

I think we can skip the re-recording part.
The re-recording logic was the condition itself that you've mentioned for the recording. To be honest I don't remember exactly why I called this re-recording... Its better to have it in the main feature. First I thought it may be a good idea if we record everything first, then move on to filter the recordings by this later. But letting everything record could result in a lot of duplicate responses if we call the same endpoint with the same request for example.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Extend Recording feature: record all requests and responses for all endpoints #1603

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 1 comment 1 reply

{{title}}

{{title}}

Select a reply

Extend Recording feature: record all requests and responses for all endpoints #1603

djazz90 Nov 22, 2024

Replies: 1 comment · 1 reply

255kb Nov 26, 2024 Maintainer

djazz90 Dec 3, 2024 Author

djazz90
Nov 22, 2024

Replies: 1 comment 1 reply

255kb
Nov 26, 2024
Maintainer

djazz90 Dec 3, 2024
Author