Create operations appear to be locked to HTTP 200 response codes

[bharling]

Describe the bug
I was wondering why none of the create operations in my exported schema were appearing in the schema export and it turns out that drf spectacular seems to assume those will emit a 200 response. The code is here:

https://github.com/tfranzel/drf-spectacular/blob/master/drf_spectacular/openapi.py#L852

I think this is actually a bug as the default response code for a create operation should be 201. I noticed that in generated client libraries the create operation responses are always returning nothing since there is no schema defined for it. I've subclassed the AutoSchema for my project to pick up the create operations and fill in the 201 responses by default but I'd propose this should be added.

To Reproduce
Generate a schema from any standard DRF ModelViewset.

Expected behavior
Create operations should emit schema along the lines of:

      responses:
        '201':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Action'
          description: ''

Actual

      responses:
        '200':
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Action'
          description: ''

[bharling]

I guess a sensible alternative might be a way to specify a mapping of operations and default response codes in the SPECTACULAR_SETTINGS ?

[tfranzel]

hi @bharling, so first of all i think you are absolutely right that it should be 201 there, and we should either fix it or provide a way to remedy it.

apparently some openapi-generator targets behave differently in this regard. we have a large API with quite a few viewset "creates" and the typescript-fetch (v5.0.0-*) client does indeed work there without modification. that this is the reason why i haven't identified this as a issue.

I was wondering why none of the create operations in my exported schema were appearing in the schema export

just to clarify your sentence. afaik, all the creates are present in the schema yaml (and swagger-ui!), just not as 201 but as 200. so technically nothing is really missing. that is my current understanding. however, your client generator target "swallows" the responses due to an "unexpected" response code. is that accurate? which target are you using?

[bharling]

Yeah thats right, the responses come back as empty because my api emits a 201 code and the generated client has no specification for that. the response schema is present but is expecting a 200. I'm using the openapi python generator for this (long story....)

[bharling]

we too have a very large API with a staggering number of viewsets.... lots of fun

[tfranzel]

alright, got you! the change should be easy, but i have to thoroughly look at the impact.... haha.. yeah, code always grows in unexpected ways. 😄

[tfranzel]

lets try this out. 201 for ViewSet creates. however this only applies there and other POST codes have to be manually changed with @extend_schema as it's safer to assume 200 for the generic case imho.

turns out the client is identical for typescript clients. the python client however does care and is quite nitpicky about it. simply returns None if return code is not in the response code dict.

[bharling]

Cool - looks almost identical to the workaround I added in our project which definitely solved it - I'd say that does the job for sure 👍

thanks!