No support for explode field in array query parameters

[shike99]

For example, an optional query parameter of a string value, allowing multiple values by repeating the query parameter:

/path:
  get:
    parameters:
      - name: id
        in: query
        description: ID of the object to fetch
        schema:
          type: array
          items:
            type: integer
        explode: false

so this will be interpreted as /path?id=1,2,3, but the committee middleware will give a 400 response with this body:

"{\"type\":\"bad_request\",\"message\":\"#/paths/~1path/get/parameters/2/schema expected array, but received String: 635\"}"

This is the specification of OpenAPI.
https://swagger.io/docs/specification/serialization/#query
https://spec.openapis.org/oas/v3.0.2#fixed-fields-9

[shike99]

When it has no explode option (so the given path: /path?id=1&id=2&id=3), the committee middleware will still give a 400 response with same body.

[mnj93]

I'm facing this same issue while trying to validate inputs for an array but it's not working and I'm getting following error:

{
    "id": "bad_request",
    "message": "#/paths/~1api~1v1~1orders/get/parameters/2/schema expected array, but received String: a,b"
}

@shike99 did you fix this one or using any other alternative for this one?

[shike99]

@mnj93
I used the other alternative like this.

swagger.yml

/path:
  get:
    parameters:
      - name: ids
        in: query
        description: ID of the object to fetch
        schema:
          type: string
          example: 1,2,3

Rails application

For example, in a controller:

class TestController < ApplicationController
  def index
    ids = params[:ids].split(',') # ids => [1, 2, 3]
  end
end

[mnj93]

@shike99
Thank you for your response.
Even I was thinking about doing the same and validating this at the controller level for now.

[ahx]

Hi. Imagine committee would support this and that you would have an optional "list" query parameter of type array in your API description and you get a request like /pets?list=& – Should a validation middleware interpret this as a null value (and return 400) or as an empty array and pass validation?

[ota42y]

I found out how to interpret it (/pets?list=&) in OpenAPI 3 specification.
https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#style-examples

When we use query, style is form by default and explode is true ( When style is form, the default value is true)
So we should interpret /pets?list=& as empty.

Since we know this value's type is array using type properties, so we should use empty array.

(And we should fix other library to resolve this issue so I created new issue ota42y/openapi_parser#122 )

[ahx]

Here is an issue that is probably related to this: #369

[pechorin]

This dirty patch helps me to find missing required param with '[]' in name. Maybe this transofrmation should be placed in separate method. Not sure.

class OpenAPIParser::ParameterValidator
  class << self
    private

    def convert_key(k, is_header)
      is_header ? k&.downcase : k.sub(/\[\]$/, '')
    end
  end
end

[ahx]

This and all variants of explode and style is supported by openapi_parameters. If you think it is feasible, I would like to help using it in committee.

About the "empty array case" with /pets?list=&: in openapi_parameters this currently does not get converted to an array, but the empty string is returned instead, but the spec is pretty vague on this and I would like to learn more

[AjaxVM]

I just added a PR to openapi_parser to incorporate a similar fix as the Monkeypatch @pechorin provided above (which is working great for us as well currently) - hopefully we can get that functionality merged upstream since the validation here just proxies over to openapi_parser for parameter checking.

ota42y/openapi_parser#166