OpenAPI: Map renderers/parsers for request/response media-types. #6865
Conversation
|
@carltongibson and this one too 😄 |
|
HI @knivets. Yes. It's on the list. Just a question of bandwidth. They're not forgotten. 👍 |
There was a problem hiding this comment.
Hi @knivets. OK, this looks great.
We could probably just do with some tests checking a view with different parsers/renderers, to confirm the request/responses are correctly generated. Do you have the bandwidth to add a couple of those?
carltongibson
force-pushed
the
openapi_multipart
branch
from
549fec6 to
0e7954d
Compare
|
(I squashed, rebased, and edited a little bit...) |
carltongibson
changed the title
carltongibson
force-pushed
the
openapi_multipart
branch
from
0e7954d to
324242b
Compare
|
Sure, I'll try to add some tests by the end of the week. |
|
Hey @carltongibson, please have a look at the updates I've pushed. Let me know if you have any feedback. |
|
Any update on this @carltongibson? |
|
Hi @knivets. Sorry for the delay. Been Busy™. Looking good — I'll have a proper look this week. 🥇 |
|
No worries @carltongibson |
There was a problem hiding this comment.
OK, great stuff. Sorry for the delay in getting to you @knivets! Thanks so much. 🥇
carltongibson
changed the title
Issue #6863
TL;DR I ended up implementing an automatic parser/renderer mapping to corresponding request/response media type. The tests are passing.
So while testing this I discovered that every endpoint that supports request body, accepts multipart requests even if there are no file fields in serializers. This is correct since this is how DRF default parsers setting actually works. So there is no longer a need to handle endpoints that accept files in a special way. Anyway, this is just an idea let me know what you think @carltongibson @tomchristie