Sending an object list in the URL

[heldersepu]

This is coming from my research on Issue #4056
It seems that arrays of objects are not quite easy/intuitive to send from the UI....
The list of integers or strings are working fine. But not the list of objects...

Q	A
Bug or feature request?	Bug (Maybe)
Which Swagger/OpenAPI version?	Latest
Which Swagger-UI version?	Latest
How did you install Swagger-UI?	swagger-net
Which browser & version?	Chrome
Which operating system?	Win 10

Demonstration API definition

http://swashbuckletest.azurewebsites.net/swagger/ui/index?filter=ArrayTest#/ArrayTest/ArrayTest_Get3

Expected Behavior

Here is how we properly send an object list in a .NET WebApi:
http://swashbuckletest.azurewebsites.net/api/ArrayTest/list_location?p[0][Lat]=1.11&p[0][Lon]=2.22&p[1][Lat]=5.55&p[1][Lon]=6.66
Here is a breakdown of the params

?
  p[0][Lat]=1.11&
  p[0][Lon]=2.22&
  p[1][Lat]=5.55&
  p[1][Lon]=6.66

Current Behavior

The current implementation seems to url encode the items and concatenate them
http://swashbuckletest.azurewebsites.net/api/ArrayTest/list_location?p=Lat%3D1.1&p=Lat%3D5.55
I've tried a lot of different combinations and nothing, I've not seen an output close to the expected behavior

Possible Solution

...Still banging my head for one possible solution.

[heldersepu]

@webron looking at: #3822 (comment)
If in OAS2, query parameters can't be of type object.
Maybe an object list is not a valid spec either, just strange that it passes validation

[mevl]

Well, in OAS 3.0 deepObject style is declared.
My parameter looks like this (in #components/parameters section):

  "filter": {
    "name": "filter",
    "in": "query",
    "schema": {
      "type": "object",
    },
    "style": "deepObject",
    "explode": true
  }

Swagger UI in TryIt mode render a simple text input field fot this parameter, the value "test" will be serialized to filter[0]=t&filter[1]=e&filter[2]=s&filter[3]=t query string. Latest Swagger UI still not support OAS 3.0 deepObject serialization?

[shockey]

@mevl, that sounds like #4071, which I'm actually looking at today!

[mevl]

@shockey, no, there is simple (not indexed) array (now "style": "form" serialization). It's works fine.

I need url-encoded real deep object like this ?filter[name]=ivan&filter[birth-date][qte]=1970-01-01 etc. In OAS3 it's called "style": "deepObject", "explode": true. This case hasn't examples in OAS3 and doesn't work in Swagger UI as expected.

[championswimmer]

Would confirm that the serialization isn't working,
It takes the object to be of type string and makes
filter[0]={&filter[1]="&filter[2]=i&

[jfboismenu]

I seems like the serialization is still not working. I've tried both Swaggerhub and running swagger-ui locally (node_modules/swagger-client/package.json:_id is indeed 3.4.8) and it still gives the same error. Can anyone else confirm this?

[shockey]

@jfboismenu, the original ticket was about bad result data, not an error message - can you open a new ticket for the error you're getting?

Thanks!

[mbandrewfoster]

I am having the same issue as @mevl

parameters:
  filterParam:
    in: query
    name: filter
    description: Options for filtering the results
    required: false
    schema:
      type: object
    style: deepObject
    explode: true

Doesn't matter what you enter into the string for "Try It Out" it just splits all the characters up into an entry into the array.

This is on swaggerhub by the way.

[championswimmer]

Yeah my fix commit didn't really do the job fully. There's something else I am missing

[shockey]

Reopening!

[championswimmer]

@shockey anywhere else in the process a String#split() takes place ? I can't seem to find any

[bajtos]

I need url-encoded real deep object like this ?filter[name]=ivan&filter[birth-date][qte]=1970-01-01 etc. In OAS3 it's called "style": "deepObject", "explode": true. This case hasn't examples in OAS3 and doesn't work in Swagger UI as expected.

Would confirm that the serialization isn't working, It takes the object to be of type string and makes filter[0]={&filter[1]="&filter[2]=i&

We are running into the same problem in LoopBack (see
loopbackio/loopback-next#1679) using swagger-ui-dist@3.17.0, which is the latest version published to npm. (Strangely enough, the latest swagger-ui version is 3.18.3 - is that gap intentional?)

@mevl @championswimmer Have you found any (workaround?) solution for this problem?

I found the following two comments that may be relevant for us:

swagger-api/swagger-js#1140

Limitations:
deepObject does not handle nested objects. The specification and swagger.io documentation does not provide an example for serializing deep objects. Flat objects will be serialized into the deepObject style just fine.

swagger-api/swagger-js#1140 (comment)

As for deepObject and nested objects - that was explicitly left out of the spec, and it's ok to just Not Support It™.

@shockey @webron What's your opinion on this? If we contributed a patch to swagger-js that will serialize deeply-nested properties using the style described above, would you accept such change, despite the fact that OpenAPI specification does not explicitly describe how to serialize deeply-nested properties?

FWIW, this serialization style is supported by https://www.npmjs.com/package/qs, which is used by http://expressjs.com as the default query parser, which means that a vast number of Node.js API servers are already expecting this serialization style.

[bajtos]

Also, since the problem of deeply-nested objects may be slightly different from the original problem described in this issue, should I open a new issue to keep track of this discussion?

[championswimmer]

This shockey/swagger-js@8818f2d
didn't fix the issue. It is the same PR I created (which, like I said, is not covering all the places String#split() is used.
Should be reopened

[bajtos]

I created a new issue in swagger-js, sometimes it's best to not start a new discussion in an old issue that has been closed long time ago.

Let's continue our discussion there: swagger-api/swagger-js#1385

[bajtos]

FWIW, I created a proposal to enhance OpenAPI spec to support deep objects - see OAI/OpenAPI-Specification#1706.