Autorest: Support "multi" collectionFormat

[amarzavery]

Please look at the collectionFormat definition and the set of valid values over here https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#parameter-object

At bare minimum we need to support multi so that swagger petstore json http://petstore.swagger.io/v2/swagger.json can be run flawlessly for generating samples.

[brjohnstmsft]

:+1:

[brodyberg]

It's ridiculous that petstore fails

[gitfool]

:+1:

I'm hitting this problem with a Swagger spec generated via Swashbuckle for a Web API:

[HttpGet]
[Route("ByIds")]
public HttpResponseMessage GetByIds([FromUri] Guid[] ids)

The resulting Swagger.json contains:

"parameters": [
  {
    "name": "ids",
    "in": "query",
    "required": true,
    "type": "array",
    "items": { "type": "string" },
    "collectionFormat": "multi"
  }
],

... and AutoRest proxy generation fails with error:

error: [FATAL] Error generating client model: Collection format "multi" is not supported (in parameter 'ids').

[MarkLie]

Hi, I would like to emphasize, that this is very important for me, because I would like to be able to upload several files at once.

My desired swagger.json contains something like this:

"parameters": [
    {
        "in": "formData",
        "name": "files",
        "description": "",
        "required": true,
        "type": "file",
        "collectionFormat": "multi"
    }
]

Kind Regards,
Mark

[koolraap]

It's interesting the Azure APIs haven't run into this problem. Maybe not supporting multi is a conscious design decision to promote API stability: A List<> parameter is not extendable, but an object containing a List<> is.

[CL0SeY]

:+1:

[fearthecowboy]

Howdy!

In our planning for driving towards a stable '1.0' release, I'm marking this issue as 'deferred' :zzz: and we're going to review it during the post-1.0 planning cycle.

_It's not to say that we're not going to work on it, or that this isn't not important, but at the moment, we're picking and choosing the stuff we must do before 1.0._ :horse_racing: :horse_racing: :horse_racing:

We'll make sure we pick this back up at that point. :tada:

[wldkrd1]

Hi, just coming across this now. As I understand it, AutoRest's entire reason for being is to generate a proxy from a Swagger 2.0 json file. Without this feature, it's impossible. Seems to me that it's premature to release a 1.0 version without the ability to truly handle Swagger files. Here's an example snippet from TripWire Enterprise which AutoRest can't handle:

   "/homepages" : {
      "get" : {
        "tags" : [ "homepages" ],
        "summary" : "Search homepages",
        "description" : "Returns a list of all homepages or only those homepages that match the provided filter criteria.",
        "operationId" : "getAll",
        "produces" : [ "application/json" ],
        "parameters" : [ {
          "name" : "id",
          "in" : "query",
          "description" : "IDs of homepages to fetch.",
          "required" : false,
          "type" : "array",
          "items" : {
            "type" : "string"
          },
          "collectionFormat" : "multi"
        },

[fearthecowboy]

@wldkrd1

Getting to 1.0 'stable' is more about reliability than 100% surface completion. (Really, all version numbers are just vanity 😃 , right? )

There are changes that I'd like to be able to make to support some things better (or actually implement properly) rather than we currently can, but that has to happen in a post-1.0 world.

We're looking at extremely short-cycle to get to 1.0 (late August) -- past that, I really want to make it easier to extend, and do that in a hurry.

[wldkrd1]

AutoRest will reliably crash 100% of the time on valid Swagger.json files, so I suppose that qualifies as stable... :-P

[fearthecowboy]

Re-opening this issue and tagging for 1.0 release -- new 1.0 criteria includes supporting petstore.

[wldkrd1]

Adding full swagger.json from TripWire Enterprise for testing/validation
swagger.zip

[annatisch]

@John-Hart,
After have a look through the specification docs for collectionFormat=multi, I'm still a little unsure about what the desired generated request should look like. Are you able to implement some AutoRest server tests for this for query and formdata? That would help me get started on the Python support.
Thanks!

[John-Hart]

@annatisch I hope to have a PR out for support for Queries in C# for this today. Right now we don't support any collectionFormat in formData so I'm going to open a separate issue to add that support.

According to the spec (https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#parameter-object) each item in the array should be a separate parameter instance:
For example: "http://petstore.swagger.io/v2/pet/findByStatus?status=pending&status=sold".

Unfortunately, if you try this with petstore sample service it will only return items that are pending. Even though the json is using multi collection format the service is expecting it to be in csv. See: https://github.com/swagger-api/swagger-samples/issues/60

[John-Hart]

Opened a separate issue to address formData: #1357

[anouarhassine]

Hi everyone,

I see that this issue is planned for the 1.0 version. Is it possible to have it in the next package (0.17.0)?
Because the actual version of Autorest does not work with the Swagger Petstore sample. We are using Autorest and it's important to get the Swagger "official" sample working.

Thanks

[annatisch]

Hi @anouarhassine,
Which language did you need the feature supported in? It's currently supported in both C# and Python - so these two languages will have this feature in 0.17.0. However you can access it now through the nightly builds.

[anouarhassine]

Hi @annatisch ,
I actually need it for C#. So it's all good. Because I saw that this issue was planned for 1.0 version.

Thanks!

[arnederuwe]

Nightly builds work fine for string based collections. No luck with List of nullable int though.
The service client generates System.Uri.EscapeDataString(_item ?? string.Empty) for nullable ints, which isn't valid c# code.
@John-Hart this is easy enough to fix I think, a type check in the templating code with an _item?.ToString() if it's a nullable type? Or am I being naive here? :)

[fearthecowboy]

Nightly 1.0 builds support non-nullable lists of int.

@olydis can give you an example. :D

[OotnBoot]

Having a similar issue to @arnederuwe , generated code puts a nullable guid into System.Uri.EscapeDataString(_item.ToString() ?? string.Empty). Adding .ToString fixes it.

[imkheong]

Not sure if this helps.

I had a similar issue where I have an Web API method that looks like this:

        [HttpGet]
        public async Task<RequestOutcome> ProcessRequest(
            [FromQuery] RequestModel requestModel)
        {
                ...
        }

        [**HttpPost**]
        public async Task<RequestOutcome> ProcessRequest(
            [**FromBody**] RequestModel requestModel)
        {
                ...
        }

I have Swashbuckle to generate the swagger.json file, which was then used by AutoRest.exe to generate a REST client.

By changing the HTTP verb from GET to POST, and changing the attribute [FromQuery] to [FromBody], it will not complain about having 'multi' in the input parameter.

I think the constraint is likely to be due to the limitation on query string length that each browser has imposed. Refer here for the information on query string length limit for browsers.

[dlgit]

Does Nightly builds support list of nullable int now?

[olydis]

no, it should make it into today's nightly, i.e. be available tomorrow

[dlgit]

Thank you. It works.

[mwherman2000]

This is still broken in Visual Studio 2017. Was it ever fixed?

[fearthecowboy]

Are you referring to the autorest version that's built-into visual studio? -- That's incredibly old, and we didn't update that (we've changed the whole way autorest works).

You are going to need to install node and use autorest from the command line.

[kgreed]

Yes I was using the version that comes with Visual Studio, Thanks I will try from the command line

[mwherman2000]

@fearthecowboy Perfect. It's working now :-) Is there a capability builtin (or in another project) to turn the serialized HTTP response Content back into C# objects (e.g. some sort of automatic DTO transformations)?

[fearthecowboy]

The generated code should contain model classes for responses that are modeled in the swagger file. I'd have to see your swagger to know more about what you're looking for.