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

PathMustBeUnique doesn't consider the HTTP Method #1449

Closed
j2ghz opened this issue Nov 2, 2023 · 3 comments
Closed

PathMustBeUnique doesn't consider the HTTP Method #1449

j2ghz opened this issue Nov 2, 2023 · 3 comments

Comments

@j2ghz
Copy link

j2ghz commented Nov 2, 2023

Describe the bug
#474 introduced a PathMustBeUnique validator, but it only check that a path is unique.

To Reproduce
Steps to reproduce the current behavior:
Have 2 endpoints with the same path but different method, e.g. GET /user and DELETE /user

Expected behavior
It should check that a combination of HTTP method and path is unique.

@darrelmiller
Copy link
Member

Are you creating the GET and DELETE operations under two different path items? If you create both GET and DELETE under the same path Item there should not be any error. Can you show an example of an OpenAPI description that gives you an error.

@marcusber
Copy link

@darrelmiller :

Created a small test to illustrate the problem.

The controller looked like this:

using Microsoft.AspNetCore.Mvc;

namespace OpenApi.IntegrationTest;
[Route("api/v2/someroute/areatype")]
public class TestController : ControllerBase
{
    [HttpGet("{index}/{arg}")]
    public ActionResult Get(long index, string arg)
    {
        return Ok("Get");
    }

    [HttpPut("{index}/{language}")]
    public ActionResult Put(int index, string language, string text) {
        return Ok("Update");
    }
}

@baywet
Copy link
Member

baywet commented Feb 27, 2025

Thank you for the additional information.

This is actually exactly prevented by the specification because it leads to ambiguous resolution.

This would need to be addressed at the specification level where the path parameters should be disambiguated considering the type as well.

Closing as until the specification changes, there nothing that can be done here.

@baywet baywet closed this as not planned Won't fix, can't repro, duplicate, stale Feb 27, 2025
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

4 participants