We have added some improvements to our existing support for how request body Content-Type
headers were handled during import. These changes can reflect in your output for SDK/portal generation or API transformations.
These changes will only affect you if you choose to re-transform or re-import your files. Please review this changelog carefully and make any adjustments to your API description files, if necessary, to avoid any issues.
Details
A request body's content type information is determined from its Content-Type
header. If explicitly present in the API specification document, it is expected to be sent as is when the API calls are made with the generated SDK or portal. If, however, the header is not defined by the user, the Content-Type
header value is automatically determined from the request body's type definition and sent.
Until today, the import behavior regarding the Content-Type
headers has been largely inconsistent e.g. for certain API description formats, we ignored the user defined Content-Type
entirely. This has now been improved and you can find format-specific details about the changes below:
- For OpenAPI (
v3.x
,v2.0
,v1.x
), RAML (v1.0
,v0.8
), Insomnia (v3
), HAR and WADL (2009
), theContent-Type
information was being ignored completely. Upon the API description import, we will now add a fixed valueContent-Type
header in the API definition explicitly. The value of this header will be determined from either the user definedContent-Type
header (if present) or from the request body media type e.g. the media type in the following example is "application/json".
"requestBody": {
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/User"
}
}
}
}
- For Postman (
v2.x
,v1.0
) and API Blueprint, aContent-Type
header was being added upon import already. However, now the headers will be considered fixed-value or constant by default, which was not the case before.
How to Disable This Feature?
The changes described above can add a new header in any form of output you generate from your API description files. If you do not wish to receive these changes, please upload a Metadata file along with your specification file at the time of importing/transforming your API description file with the ImportRequestBodyContentTypeHeader
import setting disabled.