Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support all styles of Open API/swagger parameter serialization #6906

Closed
MikaelUmaN opened this issue Jan 21, 2019 · 9 comments
Closed

Support all styles of Open API/swagger parameter serialization #6906

MikaelUmaN opened this issue Jan 21, 2019 · 9 comments
Labels
area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates

Comments

@MikaelUmaN
Copy link

MikaelUmaN commented Jan 21, 2019

Is your feature request related to a problem? Please describe.

I would like to be able to choose what style to use for array parameters (and complex parameters in general) in Web Api methods.

https://swagger.io/docs/specification/serialization/

I want to be able to have comma-separated values, rather than ampersand concatenated. This prevents some APIs from becoming way to verbose and not user-friendly.

Describe the solution you'd like

Support for global conventions to use when serializing.
Support for local overrides of that convention via attribute annotations:

[FromQuery(style=form,explode=false)] int[] userIds

Then I can call the method using a URL containing: userIds=1,2,3

Above is for v3. For v2 the collectionFormat should be able to be declared for lists and arrays.

Describe alternatives you've considered

  • Customized serialization. But if I customize, then I won't be able to use tool chains like NSwag to generate clients, and I won't get any leverage from my customization investment.
@pranavkm
Copy link
Contributor

But if I customize, then I won't be able to use tool chains like NSwag to generate clients

I don't think either of the two OpenAPI toolchains we document and test against - NSwag or Swashbuckle - support the OpenAPI v3 spec. The v2 spec does not have a way to represent query string serialization format. Even if AspNetCore \ MVC added support for specifying the serialization format, your Swagger document wouldn't have a way to represent it.

@MikaelUmaN
Copy link
Author

Under Array and Multi-Value Parameters you can see the v2 alternative of ”collection” style. Csv is the default but aspnet uses ”multi” with ampersands.

Why?

@Eilon Eilon added the area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates label Jan 23, 2019
@RicoSuter
Copy link

NSwag already supports most of the OpenAPI 3 features, see RicoSuter/NSwag#945

@RicoSuter
Copy link

It would make sense to add this so that the model binder acts on it and the spec generators can read it via api explorer

@RicoSuter
Copy link

At the moment I think you have to customize the model binder and implement a custom nswag operation processor which correctly transforms the parameters...

@pranavkm
Copy link
Contributor

You're right about the multi-value parameters, I missed that section of the spec. I've added it to our Swagger improvement tracking issue - #4854.

@Tratcher does AspNetCore support using commas as separator in query string?

@XomegaNet
Copy link

Btw, jQuery's param() method serializes arrays with square brackets by default (see examples below for versions >=1.4), which does not work with AspNetCore.

// <=1.3.2:
$.param({ a: [ 2, 3, 4 ] }); // "a=2&a=3&a=4"
// >=1.4:
$.param({ a: [ 2, 3, 4 ] }); // "a[]=2&a[]=3&a[]=4"

It would be great if AspNetCore supported that format as well. Note that it works fine in the old Web API for .Net Framework.

@mkArtakMSFT
Copy link
Member

Thanks for contacting us, @MikaelUmaN.
We do not plan to provide customization for query string parameter separation.

@ghost ghost locked as resolved and limited conversation to collaborators Dec 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-mvc Includes: MVC, Actions and Controllers, Localization, CORS, most templates
Projects
None yet
Development

No branches or pull requests

7 participants