search

firecamp-dev / firecamp

Developer-first OpenSource API DevTool, Postman/Insomnia alternative.
https://firecamp.dev
GNU Affero General Public License v3.0
1.92k stars 122 forks source link

[bug]: When saving a request response the body is not saved to the route/request #165

Open TrevorBenson opened 8 months ago

TrevorBenson commented 8 months ago

Describe the bug Saving a response does not properly save the response body.

After defining a route and clicking send the response opens a body in the right side panel, but the body of the route/request is empty. Clicking save says it saves request changes, I presume because the headers in the center (of the route/request) show Content-Type: application/json, but the

To Reproduce Steps to reproduce the behavior:

  1. Define a request (route)
  2. Click the Send button
  3. Observe the responses Body, Headers, Timeline, Test Result appear in a side panel to the right of the requests normal (center) Body, Auth, Headers, etc.
  4. Observe the requests normal (center) Headers are updated.
    • In my case it was Content-Type: application/json.
  5. Observe the request's normal (center) Body is empty.
  6. Click the Save button, and observe it mentions saving the request.
  7. Close the request.
  8. Open the request.
  9. Observe that the Body in the center panel is empty, while the Header Content-Type correctly loads, there is no right side panel with the prior request response details.

Expected behavior The body should be saved with the response when clicking save. Presumably in the center panel since that is what appears to be loaded and it has a Body tab.

Desktop (please complete the following information):

Additional context If I copy the body from the right-side panel, paste the text into the normal (center) Body field, then click the Save button, close the request, and open it again, the body does save and restore properly.

Nishchit14 commented 8 months ago

Yes, the request body and other infos are being saved. The responses are not being saved as they are temporary and may change based on the different request parameters. We have plan to built the EXAMPLE feature as per the OpenAPI spec, In that case I think this usecase will be fulfilled.