Response validation marks undefined responses as valid

[Sven Strothoff]

I am planning to use response validation in a project. While trying out different things to see what happens, I stumbled across two behaviours that might be a bug or at least not what I expected.

I checked the documentation and open issues and could not find any information about the expected behaviour in these cases.

Status codes

Behaviour: Specifying a status code that is not defined is always valid.
Expected behaviour: If a status code is not defined I would have expected any body to be invalid as it is not specified.
Example: Using /pet/{petId} (operation getPetById)from the pet store example:

      responses:
        "200":
          description: "successful operation"
          schema:
            $ref: "#/definitions/Pet"
        "400":
          description: "Invalid ID supplied"
        "404":
          description: "Pet not found"

The call api.validateResponse({ name: 'Garfield' }, 'getPetById', 204) is valid, although no response for status code 204 is defined.

Empty responses body

According to the OpenAPI specification a response with an empty response body is defined by not specifying content. (see https://swagger.io/docs/specification/describing-responses/#empty)

Behaviour: Any body for an empty response is marked as valid.
Expected behaviour: A response is only valid if it is indeed empty (i.e. undefined or '')

While I can imagine that marking undefined responses as invalid (e.g. error responses) all the time can be annoying, it would be great to have the option of a strict validation.

[Viljami Kuosmanen]

Good proposals!

I personally don't use (or really see any need for) runtime response validation in my projects.

Happy to accept PRs to implement these checks though 🙏