Allow parameter to be a discriminator

[janet]

Can we allow the path parameter to become a discriminator?

discriminator:
        parameterName: pet_type

When a path parameter is an enum, I would like to map the path parameter value to a specific response:

discriminator:
  parameterName: pet_type
  mapping:
    dog: '#/components/schemas/Dog'
    cat: '#/components/schemas/Cat'
    lizard: '#/components/schemas/Lizard'      

Currently the discriminator must be a propertyName. I am wondering if there are plans to add this in the future or if there is a way to do this that I am missing.

Full example below:

paths:
  /pet/{pet_type}/:
    get:
      parameters:
        - name: pet_type
          in: path
          required: true
          schema:
            type: string
            enum:
              - cat
              - dog
              - lizard
      responses:
        200:
          $ref: '#/components/responses/MyResponse'
components:
  schemas:
    Pet:
      type: object
      properties:
        some_property:
          type: string
    Cat:
      $ref: '#/components/schemas/Pet'
    Dog:
      $ref: '#/components/schemas/Pet'
    Lizard:
      $ref: '#/components/schemas/Pet'
    MyResponseType:
      oneOf:
      - $ref: '#/components/schemas/Cat'
      - $ref: '#/components/schemas/Dog'
      - $ref: '#/components/schemas/Lizard'
      discriminator:
        parameterName: pet_type
        mapping:
          dog: '#/components/schemas/Dog'
          cat: '#/components/schemas/Cat'
          lizard: '#/components/schemas/Lizard'      
  responses:
    MyResponse:
      description: response
      content:
        'application/json':
          schema:
            $ref: '#/components/schemas/MyResponseType'

[ayZagen]

This would be great to have as some could have lots of nested endpoints

[wuuti]

That would be great. The discriminatorObject could be enhanced with a "location" (where the default value is still "property", to stay downwards compatbile):

discriminator:
    in: property
    parameterName: pet_type

This way discriminators could come from different sources, like the requested path parameter.

discriminator:
    in: path
    parameterName: pet_type

That might also allow things like having the discriminator being set by a header

discriminator:
    in: header
    parameterName: x-pet-type

or cookie:

discriminator:
    in: cookie
    parameterName: pet-filter

[spaceone]

I also need a path to be the discriminator.

[rafalkrupinski]

What's the point of having a bunch of identical types?

[darcyrush]

The enhancement @wuuti proposes would be amazing. I have different use cases for discrimination for both a query parameter and a path parameter

[yonatane]

+1

It would also be great to define the discriminator to be anything from the input: any path param, query param, and any nested field in the body.

[Yugi-2]

@handrews Is this kind of enhancement going to be on the roadmap for any 3.X release? I've seen #2143 regarding deprecation

Not sure if #3601, using $dynamicRef, can help accomplish the same thing. I know Moonwalk will address request/response correlation, but will there be anything in a 3.X that allows specifying a different response schema based on a path parameter?

[handrews]

@Yugi-2 I doubt this will be done in 3.x as extending discriminator (already one of the most complex and difficult-to-implement-correctly parts of the specification) to correlate with things outside of Schema Objects would involve a lot of work to support.

I'm going to mark this as "Moved to Moonwalk" – all new request/response correlation work is happening there, and we already decided that anything that can be backported to 3.x with a reasonable amount of effort will be. So there's no need to track this specifically. I'm not going to literally move this issue to the moonwalk repo because the "signatures" idea definitely includes this sort of thing already.