-
Notifications
You must be signed in to change notification settings - Fork 266
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
Relax "only unsafe methods can have a requestBody" constraint #809
Comments
Hi Glenn, I get your point. This has been raised a couple of times. See here for my previous comment #431 (comment)
From https://spec.openapis.org/oas/v3.0.3#operation-object
From https://spec.openapis.org/oas/v3.1.0#operation-object So you could say this was relaxed a bit, but still strongly discouraged. At the moment we only support My stance was that we will not support this officially as long as it violates the spec. This could of course be lifted once we move to |
Thanks for the reply! Not sure how I missed finding #431 before. Feel free to close this as a duplicate if you like. :-) I will point to the discussion on OAI/OpenAPI-Specification#1937 - it was originally going to be permitted in v3.0.3 but the point was raised that that might be a SemVer violation, so it was backed out and changed only in 3.1.0 instead. |
Sure! I'll leave this open as a reminder for 3.1 support. |
Hi, just wondering if the support for OpenAPI 3.1 is in the plan? |
Describe the bug
drf_spectacular.openapi.AutoSchema
asserts that "only unsafe methods can have a body" and therefore will not render arequestBody
for a DELETE endpoint, even if the view function is decorated with@extend_schema(request=...)
. While I'm aware that the relevant standards discourage including arequestBody
in a DELETE, there are nevertheless existing APIs that do expect such. The OpenAPI 3.1 spec also permits (but discourages) this pattern:It would be useful for drf-spectacular to relax this constraint so as to allow more accurately documenting such non-standard REST APIs.
At present I've worked around this in an
AutoSchema
subclass by overridingget_operation()
to explicitly re-add therequestBody
back to the appropriate set of DELETE endpoints, but it would be nice to not have to do so.(Another more targeted approach would be to directly override
_get_request_body()
to remove this check but I hate to override private methods).To Reproduce
Decorate a
delete
endpoint with@extend_schema(request=...)
and observe that the generated schema still reports norequestBody
for this endpoint.Expected behavior
Appropriately-decorated DELETE endpoints should be represented in the generated schema with an appropriately constructed
requestBody
.The text was updated successfully, but these errors were encountered: