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]

👍

[brodyberg]

It's ridiculous that petstore fails

[gitfool]

👍

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]

👍

[fearthecowboy]

Howdy!

In our planning for driving towards a stable '1.0' release, I'm marking this issue as 'deferred' 💤 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. 🏇 🏇 🏇

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

[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.