-
Notifications
You must be signed in to change notification settings - Fork 261
Resurrect :responses :default #735
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
Conversation
it is an old feature, but didn't have a test, so it was broken by #715 also add a test so we don't break it again
| (ring/router | ||
| ["/foo" {:post {:responses {200 {:content {:default {:schema schema-200}}} | ||
| 201 {:content {"application/edn" {:schema schema-200}}} | ||
| 202 {:description "status code explicitly mentioned, but no :content map"} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The interaction here between :content and :default will probably mislead users.
- If a status code is listed, but has no
:content, the coercion for the:defaultstatus will apply - If a response code has a
:content, it implicitly means non-mentioned content-types will have no coercion at all
It would be clearer, IMO, to have the :default response only apply when the status code isn't listed. That is, in this case, status 202 should have no response coercion at all, for any content type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I agree that the :default response should only apply if there is an unlisted status code.
As in #691 , it would be good to explicitly and separately specify and document the recommended way of specifying that an empty response body is expected.
|
Hey @opqdonut would there be a plan to release this? Hoping to get to update to the new reitit on some of my projects, not urgent but great to have it! Thanks again! |
|
I'll try to have some time to look at this, latest next week. Feel free to ping me if you don't hear from me. |
a0cf569 to
f038fe1
Compare
|
Jotting down some notes for myself. Lookup order for coercions should be:
However, we should still be able to disable coercion with something like The OpenAPI semantics however use a lack of :schema to mean "no response allowed", so that's in conflict with reitit, which uses it to mean "anything goes". |
|
In Reitit, how do I specify that the :body must be empty? (in contrast to ":body may be anything"). |
|
Currently, the only way to do that is to use a schema that admits only |
|
I think I managed to cover all the corners. The default resolution order is now like I planned in my message above (see also: doc changes in the commits) |
|
Looks great to me, thanks a lot for the effort! |
No description provided.