Bug: encoding option in requestBody is not respected.

[Thiry1]

Steps To Reproduce

According to the OpenAPI 3.0 definition, requestBody has encoding option.
However, the encoding option is missing from the generated code.

The current behavior

encoding option is dissappear

The expected behavior

encoding option should be respected.
IMO, if Content-Type is application/x-www-form-urlencoded, encoding option is required for the type of requestBody.

[Himenon]

Thanks for the info. It looks like I will need to change the ApiClient interface to implement this.

export interface ApiClient<RequestOption> {
    request: <T = SuccessResponses>(httpMethod: HttpMethod, url: string, headers: ObjectLike | any, requestBody: ObjectLike | any, queryParameters: QueryParameters | undefined, options?: RequestOption) => Promise<T>;
}

Should I make the argument an object if I expect to add more in the future?

I would like to hear your opinion.

[Thiry1]

Should I make the argument an object if I expect to add more in the future?

IMO, accepting object as an argument is a good choice.
However this causes breaking change.So I think we have to bump major version.(It would be better to have version 1.0.0 before making this change.)

[hrsh7th]

I also agree this. I think it's a common best practice to keep public API arguments defines as dict.

[Himenon]

you can check in playground v0,25.0

https://openapi-typescript-code-generator.netlify.app/v0.25.0/index.html

Perhaps the Himenon/openapi-parameter-formatter would work well.