Currently, multipart bodies always create an API schema like this:
"content": {
"multipart/form-data": {
"schema": {
"type": "string",
"format": "binary"
}
}
}In my dropshot API, my request handler accepts this multipart body and then extracts parts from it. I expect some parts to conform to some schema. e.g. "first part should be a Person, second part should be a Workplace". This is not captured at all in the schema that Dropshot generated above, but it is required by the actual endpoint implementation code I wrote.
But the OpenAPI spec supports using detailed schemas that explain each part's expected type. So in theory Dropshot could generate a more detailed schema that captures my expectations for each part.
As the person who originally added multipart support, this oversight is purely due to me being silly a few years ago, and I think this gap should be fixed.
Currently, multipart bodies always create an API schema like this:
In my dropshot API, my request handler accepts this multipart body and then extracts parts from it. I expect some parts to conform to some schema. e.g. "first part should be a Person, second part should be a Workplace". This is not captured at all in the schema that Dropshot generated above, but it is required by the actual endpoint implementation code I wrote.
But the OpenAPI spec supports using detailed schemas that explain each part's expected type. So in theory Dropshot could generate a more detailed schema that captures my expectations for each part.
As the person who originally added multipart support, this oversight is purely due to me being silly a few years ago, and I think this gap should be fixed.