Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Version 1.6.5 to 1.6.13 contains breaking change #1572

Open
JohannesBauer97 opened this issue Feb 28, 2024 · 3 comments
Open

Version 1.6.5 to 1.6.13 contains breaking change #1572

JohannesBauer97 opened this issue Feb 28, 2024 · 3 comments

Comments

@JohannesBauer97
Copy link

JohannesBauer97 commented Feb 28, 2024

Describe the bug
We're using this package to validate OpenAPI specification files by reading the files OpenApiStringReader.Read and checking if there are diagnostic errors.
image

After updating from 1.6.5 to 1.6.13, a spec which was valid before, became invalid because of non-unique paths (see below the screenshot).

Diagnostic Error:
RuleName: "PathMustBeUnique"
Pointer: "#/paths//api/v1/{birdId}/children/{childNo}"
Message: "The path signature '/api/v1/{}/children/{}' MUST be unique."

OpenApi File To Reproduce
Just giving a screenshot here, if the full file is required I need to anonymize it first. Maybe for the discussion the screenshot is enough
image

Expected behavior
No breaking changes between patch versions.

What does the openapi spec say? Is this definition of non unique paths a error?

@VisualBean
Copy link

VisualBean commented Mar 1, 2024

Technically, the new behavior is correct.
From https://spec.openapis.org/oas/v3.0.3#paths-object

A relative path to an individual endpoint. The field name MUST begin with a forward slash (/). The path is appended (no relative URL resolution) to the expanded URL from the Server Object’s url field in order to construct the full URL. Path templating is allowed. When matching URLs, concrete (non-templated) paths would be matched before their templated counterparts. Templated paths with the same hierarchy but different templated names MUST NOT exist as they are identical. In case of ambiguous matching, it’s up to the tooling to decide which one to use.

4.7.8.2 Path Templating Matching §
Assuming the following paths, the concrete definition, /pets/mine, will be matched first if used:

  /pets/{petId}
  /pets/mine

The following paths are considered identical and invalid:

  /pets/{petId}
  /pets/{name}

The following may lead to ambiguous resolution:

  /{entity}/me
  /books/{id}

Due to templating behavior, those paths are indeed considered identical.

@JohannesBauer97
Copy link
Author

Thanks for the reference, so it was all the time defined like this, and now it got fixed in the nuget.

@rasmus-s
Copy link

rasmus-s commented Mar 6, 2024

@VisualBean the new behavior have one issue as I see it, it not taking the apiOperation into account with different template names. Should below not be allowed?

DELETE /pets/{petId}
PUT /pets/{name}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants