Open knivets opened 5 years ago
Yeah seems valid to me. Of course it’s less obvious what we should do if we have both FileField and composite field types (that multipart can’t support.)
Could you please give an example of request body with file and composite field?
Eg. Anything with both FileField and DictField
Or FileField and a nested serializer
@knivets you fancy taking a pop at this? As Tom says, we should be able to do the simple cases at least.
(There may come a complexity level where we say “use a subclass to specify this particular case” rather than try and solve everything, but we’re not there yet...)
Yes! I’ll work on this over the weekend.
@knivets Do you have an idea what is the expected schema using OpenAPI Components ? Component's goal is to keep the same properties for request and response and reference them.
In the example you posted in "Expected behavior", the format: binary
property is only in the "requestBody".
Should the schema include a different component for request and response?
I wasn't able to find any example about this on the web. Thanks!
Checklist
master
branch of Django REST framework.Steps to reproduce
Expected behavior
Actual behavior
There are two things going on here: 1) There is no support for automatic
multipart/form-data
media type generation 2) TheFileField
generates incomplete OpenAPI schema: it doesn't includeformat: binary
. Finally, it should only generateformat: binary
for requests, since you can't have a binary string field withinapplication/json
media type. We could probably add aformat: uri
in caseuse_url=True
.https://swagger.io/docs/specification/describing-request-body/multipart-requests/
On unrelated note I noticed that DRF doesn't put
type: object
underschema
even though this spec passes validation here