Swagger-UI not producing an error when query string is added to the path

[mika018]

Q	A
Bug or feature request?	Bug
Which Swagger/OpenAPI version?	3.0.1
Which Swagger-UI version?	when I run window.versions.swaggerUi in the console 3.13.5 is displayed even though I am importing a version 3.13.6
How did you install Swagger-UI?	Using maven: org.webjars.swagger-ui.3.13.6
Which browser & version?	Chrome 65.0.3325.181
Which operating system?	Ubutnu 17.10

According to this issue, Open API only uses the path portion of the resource identifier to identify operations. My expectation is that the swagger-ui will error if a path containing query parameters is set as one of the paths. For example /protected-areas/id is expected to work but not /protected-areas/id?_view=minimal.

paths:
  /protected-area/id?_view=default:
    description: default
    get:
      tags:
        - protected-area
      parameters:
        - name: type
          in: query
          description: ''
          schema:
            type: string
        - name: code
          in: query
          description: ''
          schema:
            type: string
        - name: label
          in: query
          description: ''
          schema:
            type: string
      responses:
        '200':
          description: Success
          content:
            application/json:
              schema:
                type: object
                properties:
                  meta:
                    $ref: '#/components/schemas/metaList'
                  items:
                    type: array
                    items:
                      type: object
                      properties:
                        type:
                          type: string
                        code:
                          type: string
                        label:
                          type: string
        '400':
          description: Invalid request
        '500':
          description: Internal server error
  /protected-area/id?_view=csv:
    description: csv
    get:
      tags:
        - protected-area
      parameters:
        - name: type
          in: query
          description: ''
          schema:
            type: string
        - name: label
          in: query
          description: ''
          schema:
            type: string
        - name: code
          in: query
          description: ''
          schema:
            type: string
        - name: notation
          in: query
          description: ''
          schema:
            type: string
      responses:
        '200':
          description: Success
          content:
            application/json:
              schema:
                type: object
                properties:
                  meta:
                    $ref: '#/components/schemas/metaList'
                  items:
                    type: array
                    items:
                      type: object
                      properties:
                        type:
                          type: string
                        label:
                          type: string
                        code:
                          type: string
                        notation:
                          type: string
        '400':
          description: Invalid request
        '500':
          description: Internal server error

In my case the above spec works perfectly fine, producing this result:

The UI is fully functional with no errors displayed. It is allowing me to run requests and it is displaying the results properly.

The main priority for me is allowing the users to see what properties are returned by which view and providing a different operation for each view does just that. That configuration does not meet the Open API Specification but that is not the main priority.

I am happy with the given behaviour but I am not sure if this is a bug or a feature since it is not supported by the Open API Specification. If this is going to be removed in a future version I would rather choose a different way of showing the different return formats for different views.

[webron]

Swagger-UI does not display errors on malformed API definitions (for the most part) and that's on purpose. The validation badge that you see at the bottom should give an indication if the definition is valid or not. If it doesn't produce an error, then this should be reported on the validator-badge project.

[mika018]

Thank you for your reply @webron. I cannot seem to find a validation badge so I am assuming that this is an error with the validator-badge and will forward the issue to that project.

[heldersepu]

I think that the validation badge is not shown with OAS 3.x

3.x

• http://petstore.swagger.io/?url=http://heldersepu.github.io/hs-scripts/swagger/4258_p1_swagger.yaml&docExpansion=none
• http://petstore.swagger.io/?url=http://heldersepu.github.io/hs-scripts/swagger/4214_swagger.json&docExpansion=none

2.x

• http://petstore.swagger.io/?url=http://heldersepu.github.io/hs-scripts/swagger/3366_swagger.json&docExpansion=none
• http://petstore.swagger.io/?url=http://heldersepu.github.io/hs-scripts/swagger/4263_swagger.yaml&docExpansion=none

[webron]

@heldersepu is right, I've missed that this is OAS3. We should have the validator for OAS3 up and running within a few weeks.

[lock]

Locking due to inactivity.

This is done to avoid resurrecting old issues and bumping long threads with new, possibly unrelated content.

If you think you're experiencing something similar to what you've found here: please open a new issue, follow the template, and reference this issue in your report.

Thanks!