Support for multiple query parameter combinations on a path

[gislikonrad]

Let's say you have these two routes in your API where the bold parameters are required.

1. GET - /values?type={type}
2. GET - /values?from={from}&to={to}

How would you describe this in Swagger 2.0?

Currently you can "hack" it by defining the route like the following.

paths:
  /values:
    get:
      summary: Get values
      parameters:
        - in: query
          name: type
          required: false
          type: string
        - in: query
          name: from
          required: false
          type: string
          format: date
        - in: query
          name: to
          required: false
          type: string
          format: date
      responses:
        '200':
          description: values
          schema:
            type: array
            items: 
              $ref: '#/definitions/value'

What this means is that the way the API is described, consumers could see it as being able to call GET - /values?type={type}&to={to}.

What I propose is a way to create a group or set of parameters and specify multiple possible groups or sets in a route. Example follows.

paths:
  /values:
    get:
      summary: Get values
      parameters:
        - $ref: '#/parameterSets/optional_type_filter'
        - $ref: '#/parameterSets/date_filter'
      responses:
        '200':
          description: values
          schema:
            type: array
            items: 
              $ref: '#/definitions/value'

parameterSets:
  optional_type_filter:
    - in: query
      name: type
      required: false
      type: string
  date_filter:
    - in: query
      name: from
      required: true
      type: string
      format: date
    - in: query
      name: to
      required: false
      type: string
      format: date

[VladRassokhin]

Looks like duplicate of #182

[webron]

This is a mix of #182 and #256, so let's keep the suggestions there. The suggested solution here introduces an additional level of complexity that will cause extra confusion with the potential parameter grouping in the future. I think the generic solution to #182 would be better in this case.