fix(petstore): Update petstore to conform with OpenAPI 3.0.3 spec

[rstular]

The petstore YAML is not consistent with the OpenAPI schema 3.0.2 and 3.0.3 as it uses HTTP response code 405 incorrectly (OAI/OpenAPI-Specification#1486)

Description

This changes the Pet store example schema to use HTTP return codes 422 and 400 to indicate an invalid entity instead of using 405. 400 is used to indicate that the syntax of the body is incorrect, and 422 is used to indicate that the syntax is valid, but some other aspect of the body (e.g. its structure) makes it invalid.

Motivation and Context

OpenAPI 3.0.2 has changed the description of the HTTP response code 405 from Invalid input to Method not allowed to conform with RFC7231 (see here).

The pet store example schema has the version set to 3.0.3, but it does not reflect the changes that were made to the response code description. This renders the example schema misleading, as it uses a non-standard description for the code.

How Has This Been Tested?

Ran the tests using npm run test, as well as manually inspected the results by running a local instance (see screenshots below).

Screenshots (if appropriate):

Checklist

My PR contains...

• No code changes (src/ is unmodified: changes to documentation, CI, metadata, etc.)
• Dependency changes (any modification to dependencies in package.json)
• Bug fixes (non-breaking change which fixes an issue)
• Improvements (misc. changes to existing features)
• Features (non-breaking change which adds functionality)

My changes...

• are breaking changes to a public API (config options, System API, major UI change, etc).
• are breaking changes to a private API (Redux, component props, utility functions, etc.).
• are breaking changes to a developer API (npm script behavior changes, new dev system dependencies, etc).
• are not breaking changes.

Documentation

• My changes do not require a change to the project documentation.
• My changes require a change to the project documentation.
• If yes to above: I have updated the documentation accordingly.

Automated tests

• My changes can not or do not need to be tested.
• My changes can and should be tested by unit and/or integration tests.
• If yes to above: I have added tests to cover my changes.
• If yes to above: I have taken care to cover edge cases in my tests.
• All new and existing tests passed.

[char0n]

Hi @rstular,

Thanks for opening this up! You're absolutely correct, the petstore fixture should use appropriate status codes.

[char0n]

LGTM

[frankkilcommins]

@rstular thanks for this. Indeed the representation is not leveraging the HTTP status codes appropriately. I'd prefer to have consistent descriptions while we're at it. Could you modify such that:

• 400 has description Invalid input
• 422 has description Validation exception

[rstular]

@rstular thanks for this. Indeed the representation is not leveraging the HTTP status codes appropriately. I'd prefer to have consistent descriptions while we're at it. Could you modify such that:

* 400 has description `Invalid input`

* 422 has description `Validation exception`

I've done that for all occurrences where both 400 and 422 status codes were present, but didn't touch the ones without a 422 response. Is that fine?

[frankkilcommins]

LGTM. @char0n this will likely have to be scheduled with updates to dependent components.

[char0n]

@frantuma can you please confirm that this change is aligned with https://github.com/swagger-api/swagger-petstore/ ? I've inspected the PetController.java and I could tell that Response.Status.BAD_REQUEST === 400 is returned.

Regarding to 422 status code - does the petstore webapp returns 422 in any situation?

[frantuma]

@char0n

@frantuma can you please confirm that this change is aligned with swagger-api/swagger-petstore ? I've inspected the PetController.java and I could tell that Response.Status.BAD_REQUEST === 400 is returned.

Regarding to 422 status code - does the petstore webapp returns 422 in any situation?

Swagger Petstore v3.0 current APIs implementation only return 400 or 404, no 422 or 405 are ever returned

however this version is based on spec first inflector, and its OpenAPI spec is currently using 405 in some responses. We have a note to update that, not sure if it's so important to have editor and petstore aligned..

[char0n]

As @frantuma confirmed the changes in this PR are already closer to Petstore java implementation than the old definitions without these changes. I'm going for a merge and will follow up on applying these changes to the next branch as well.