Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dealing with responses with different possible bodies for the same status code #138

Open
Uaitt opened this issue Oct 10, 2023 · 1 comment
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@Uaitt
Copy link

Uaitt commented Oct 10, 2023

While using this gem in one of my recents projects, I have faced the following issue:

A specific controller action can return a 200 and a 401 when the client is not authorized.
However, the 200 response can have very different bodies based on the headers that the client passes to the server (with very different, I mean completely different JSON structures).

I have written very comprehensive request specs, testing every possible response which can be returned by that controller action (basically, I have written a test for each possible 200 response, and the 401 response).

Currently rspec-openapi will generate an openapi.yaml with:

  • A 200 response, taken from the last example (I guess?) of the request specs for my controller
  • A 401 response

As of now, the only way I have found to add the other 200 responses is to manually edit the openapi.yaml file. Is there another way to achieve this behaviour maybe?

Thanks for your time, and thanks to the maintainers for this amazing gem ❤️ 😃

@Uaitt Uaitt changed the title Dealing with responses with many possible bodies for the same status code Dealing with responses with different possible bodies for the same status code Oct 10, 2023
@exoego
Copy link
Owner

exoego commented Oct 13, 2023

The current implementation assumes that responses from the same API share the same JSON structure.
So rspec-openapi collects API responses and merges.
I do not remember the details, but a response from the last test case overwrites the former ones.
I understand this assumption is only sometimes valid.

We may group responses by same HTTP status code and merge in each group.

Relates to #140

@exoego exoego added the enhancement New feature or request label Oct 13, 2023
@exoego exoego added the good first issue Good for newcomers label Nov 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants