Model not supported as GET Operation parameter

[fabriziofortino]

As per documentation an operation parameter type could be either an enum, a model, or a primitive type.

This does not work for GET operations though. My model / operation look like this

"models": {
    "my_model": {
      "fields": [
        {
          "name": "a",
          "type": "string"
        },
        {
          "name": "b",
          "type": "string"
        }
      ]
    }
},
"resources": {
    "my_resource": {
      "path": "/resources",
      "operations": [
        {
          "method": "GET",
          "parameters": [
            {
              "name": "qp",
              "type": "my_model"
            }
          ]
        }
    }
}

Uploading the api.json I get the following error:

Resource[my_resource] GET /resources Parameter[qp] has an invalid type[my_model]. Model and union types are not supported as query parameters.

It would be nice if query parameters models would be supported using the parameter name as prefix . In my example it would look something like this:

/resources?qp.a=value&qp.b=another_value

WDYT?

[mbryzek]

Initially this was by design as the complexity of marshaling an arbitrary object to url parameters would need to make a lot of assumption on the parsing libraries on the other end. Ultimately I think we should consider:

• leaving as is w/ out support, forcing users to document the specific query parameters and marshaling themselves and avoid assumptions on how to handle exactly all types (e.g. collections could be named foo or foo[], a field that is another model, etc.) etc.

• supporting models only where all fields are primitive types so that serialization is simple as in your example

• some other option

Would love your thoughts on (a) or (b) and also generally would love to understand how common this is for you.

[gheine]

I really like this idea. We could start with allowing only model types where all fields are primitives and expand that at a later point if needed. In general it shoud be pretty straight forward to (de)marshal nested types with the dot-notation (e.g. foo.bar.baz=blah&foo.bar.bam=boom&...)

[fabriziofortino]

+1 to support this only on models with primitives only. I think this will cover most of the cases.

[rlmartin]

Of note: Swagger also does not support non-primitive models in the querystring - so marshalling into/out of dot-notation primitive parameters works with that. One concern would be the limits on querystring size for large, complex models.

[mbryzek]

from discussion

• in ui docs, show that the query parameter is a type (e.g. name of type "Name")
• include example query string
• add section to apidoc/doc talking about model serialization