[TypeScript-Fetch] Support for non-JSON body params #6994
Conversation
|
Note: all the EDIT: I've split these changes out into a separate commit for clarity. |
masaeedu
force-pushed
the
6940-tsfetch-contenttype
branch
from
c3565f7 to
6b678f1
Compare
If the spec specifies a list of consumes MIME types, default to the first MIME type in the list instead of "application/json" (the user may still override this by passing "Content-Type" in options.headers). Additionally, only perform explicit JSON serialization if the data type of the body parameter is not "string", or if it is string, only when the content type is "application/json".
masaeedu
force-pushed
the
6940-tsfetch-contenttype
branch
from
6b678f1 to
598e90b
Compare
masaeedu
changed the title
| localVarHeaderParameter['Content-Type'] = 'application/json'; | ||
| {{/consumes}} | ||
| {{#consumes.0}} | ||
| localVarHeaderParameter['Content-Type'] = '{{mediaType}}'; |
There was a problem hiding this comment.
@masaeedu Please use {{{mediaType}}} to use the original value fo the media type as I remember there are edge cases causing issues with the HTML-escaped values.
There was a problem hiding this comment.
@wing328 Good catch. Should we be doing this for things like {{className}}, {{paramName}} etc. as well?
There was a problem hiding this comment.
FYI. I've filed #7073 to clean up {{mediaType}} in other templates.
|
@masaeedu PR merged into master. I'll fix the {{mediaType}} later. |
PR checklist
./bin/to update Petstore sample so that CIs can verify the change. (For instance, only need to run./bin/{LANG}-petstore.shand./bin/security/{LANG}-petstore.shif updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in.\bin\windows\.3.0.0branch for changes related to OpenAPI spec 3.0. Default:master.Description of the PR
This change adds support for non-"application/json" MIME types in a body parameter. The logic has some hairy bits I'm not entirely happy with, but I'm trying to follow what the other language generators do:
Instead of always emitting a default
"Content-Type"of"application/json", emit the first MIME-type from the operation'sconsumesarray if available, and fall back to"application/json"if this is not present.This is a little ugly; if the user needs to use a MIME-type from the
consumesarray that isn't the first one, they need to know to pass it inoptions.headers["Content-Type"], which isn't very visible. I'd like to make the content type an explicit, required parameter on operations where there's more than one entry in theconsumesarray, but for now I've just followed what I've seen most of the other language clients.In cases where the body parameter has datatype
stringand the content type isn'tapplication/json, simply set the request body to the parameter directly. Otherwise,JSON.stringifythe parameter as before. This doesn't take into consideration other any other possibledataTypevalues that may represent raw body streams; I am unaware of any such datatypes but if you know of any please point them out.Hopefully some of the reviewers can provide feedback on these points.
Fixes #6940.
Technical committee reviewers
@TiFu @taxpon @sebastianhaas @kenisteward @Vrolijkx