Improved handling of generic media types

[thompson-tomo]

Within the openapi spec i am using (https://api.parkassist.com/docs/index.html) it is using generic media types for requests due to supporting both json & xml.

/signs:
    post:
      description: Creates signs. Any ids specified are ignored.
      requestBody:
        description: The signs to create.
        content:
          '*/*':
            schema:
              type: array
              items:
                $ref: '#/components/schemas/ParkAssist.PaseServer.WebServices2.Dto.Sign'
        required: false

The above is generating the following method

public async Task<List<global::Skidata.Dashboard.Client.ParkAssist.Models.Sign>?> PostAsync(Stream body, Action<RequestConfiguration<DefaultQueryParameters>>? requestConfiguration = default, CancellationToken cancellationToken = default)

which is valid, however if the full media type is specified in the openapi, the below method is generated which is easy for a user to use.

public async Task<List<global::Skidata.Dashboard.Client.ParkAssist.Models.Sign>?> PostAsync(List<global::Skidata.Dashboard.Client.ParkAssist.Models.Sign> body, Action<RequestConfiguration<DefaultQueryParameters>>? requestConfiguration = default, CancellationToken cancellationToken = default)

What would be helpful is if the media type is defined as one of the below:

• star/star
• application/star

where star = *

The below method is generated, and it uses application/json

public async Task<List<global::Skidata.Dashboard.Client.ParkAssist.Models.Sign>?> PostAsync(List<global::Skidata.Dashboard.Client.ParkAssist.Models.Sign> body, Action<RequestConfiguration<DefaultQueryParameters>>? requestConfiguration = default, CancellationToken cancellationToken = default)

And it also generates which would is expecting "application/json" and if not matched, results in a failure.

public async Task<List<global::Skidata.Dashboard.Client.ParkAssist.Models.Sign>?> PostAsync(List<global::Skidata.Dashboard.Client.ParkAssist.Models.Sign> body, string MediaType, Action<RequestConfiguration<DefaultQueryParameters>>? requestConfiguration = default, CancellationToken cancellationToken = default)

When #342 is implemented that also becomes a supported media type to be passed in.

[baywet]

Hi @thompson-tomo Thank you for using kiota and for reaching out.

I'd say this description is not specific enough. From what it describes, it'd mean I could also send it an image, YAML, etc... Which I'm pretty sure the API would be unhappy with. It'd be much better for this description to have two entries, one for application/json and another for application/xml

We don't have any plans to add any "compatibility" mechanism, allowing users to say "map star/star to application/json during the generation", it'd be a slippery slope.

[michaeldcanady]

My use-case is different but is excluded by the lack of this functionality. I am working with an API where you can attach files/images/etc. to a request and in it’s documentation it says it supports / so by extensions when you call /attachment/{sys_id}/file it can return nearly any content type.

[michaeldcanady]

Here is the documentation for reference: https://www.servicenow.com/docs/bundle/xanadu-api-reference/page/integrate/inbound-rest/concept/c_AttachmentAPI.html

The section in question is: Attachment - GET /now/attachment/{sys_id}/file

[thompson-tomo]

Agree @michaeldcanady use case is deeply connected to this.

For me what would be most beneficial is if not otherwise specified it is expected that the api will return the same content type as the request for instance posting json is expected to return json unless the api or developer specifies otherwise.