Support objects in query params

[valp0]

Is your feature request related to a problem?

I'm wondering if you support objects as query params. I've been trying to use this feature, which seems to be supported by OAS 3.0, but it seems you treat objects as strings.

This is how I define an object inside a query param.

This is how it appears in the query params list.

And this is how it appears in the Send API Request side.

Am I doing something wrong? Or misunderstanding something perhaps?

Describe the solution you'd like

I'd like to know if this feature is in already considered, or will never be.

Describe alternatives you've considered

One alternative I see is using the Swagger 2.0 approach, as described here.

Additional context

I know a lot of APIs use objects inside query params, and it would be nice if this feature was implemented. Also, I know the response body does interpret objects properly, so that's probably just a bug or missing code?

Thank you very much in advance!

[welcome-to-palo-alto-networks[bot]]

:tada: Thanks for opening your first issue here! Welcome to the community!

[valp0]

Hi, @sserrata! Tagging you here for visibility. I'm not really sure whether this is a missing feature or a bug. Sorry for bugging you (pun intended) 🙂

[sserrata]

Hi @valp0, thanks for the FR! The good news is that I believe we can easily adapt how we already handle properties in the request/response bodies to parameters. The only challenge I foresee is how to support object params in the demo/explorer. My initial thought/idea is that we can either use an inline Live Editor input (similar to request body) or simply a text input. Do you know if the format should also be determined by the Content-Type, e.g. application/json vs application/xml?

[valp0]

Hi, @sserrata! Sorry for the delay. The response body does display object properties properly inside the response:

The problem is the way objects are being handled in the query params (see issue description).

And, well, I believe that can be implemented in a similar way to that of objects in response body schema. So, for example, in the request/demo panel you could have a dropdown (like the one used for objects in the response body, then each property of the object could be displayed just as a regular input inside that dropdown, with the name and type of each field of course. Then of course you'd need to serialize the object inside the actual request demo code, like /points?color[R]=100&color[G]=200&color[B]=150 (based on this).

And, about the XML vs JSON thing, I really don't know. To be honest I don't think it should be related in any way, at the end this is just the query parameters, not a request body or anything, so I think the serialization I quoted in the previous paragraph should be enough to support what we need in the query parameters.

[sserrata]

Hi @valp0, I haven't had a chance to look into this but I was wondering if you've already experimented with inputting a JSON or object literal as the input value, and whether that is properly serialized/encoded in the code snippet params?

[valp0]

Hi, @sserrata! I did experiment with that back when I was building that project. For what I can remember, it was not serialized properly; it would just stay as a normal string.

[valp0]

Hi, @sserrata! Congrats on the 3.0.1 plugin version release! I noticed you added the "roadmap" label to this issue. Is there an estimated date for this feature to be developed?

I have a real life example, if it helps. We are using your plugin to populate Salesloft's API documentation, and we do have several parameters that are really part of an object. For example, here we have the updated_at parameter but due to the current limitation described above, we had to split the properties of the object as though they are separate parameters. This achieves the same result in the curl request and it works*, however it lacks the main description of the updated_at parameter and it's visually not describing the scenario that we actually have, which is that we have an object called updated_at and it has four different properties that we accept serialized as a deep object (see query parameter serialization).

* It works for our specific use case, which is having the object serialized as deepObject and exploded.

This parameter description of a query parameter works as expected in swagger editor

          {
            "in": "query",
            "name": "updated_at",
            "description": "Equality filters that are applied to the updated_at field. A single filter can be used by itself or combined with other filters to create a range.",
            "required": false,
            "schema": {
              "type": "object",
              "properties": {
                "gt": {
                  "description": "Returns all matching records that are greater than the provided iso8601 timestamp. The comparison is done using microsecond precision.",
                  "type": "string",
                  "example": "a time"
                },
                "gte": {
                  "description": "Returns all matching records that are greater than or equal to the provided iso8601 timestamp. The comparison is done using microsecond precision.",
                  "type": "string",
                  "example": "another time"
                },
                "lt": {
                  "description": "Returns all matching records that are less than the provided iso8601 timestamp. The comparison is done using microsecond precision.",
                  "type": "string",
                  "example": "one more time"
                },
                "lte": {
                  "description": "Returns all matching records that are less than or equal to the provided iso8601 timestamp. The comparison is done using microsecond precision.",
                  "type": "string",
                  "example": "one last time"
                }
              }
            },
            "style": "deepObject",
            "explode": true
          },

however, the plugin produces this: which as you can see is still just a string input and all of its properties are left out, even though it says it's an object.