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

OpenApiPaths and Operations #472

Closed
fabich opened this issue Apr 21, 2020 · 2 comments · Fixed by #474
Closed

OpenApiPaths and Operations #472

fabich opened this issue Apr 21, 2020 · 2 comments · Fixed by #474
Labels
type:question An issue that's a question

Comments

@fabich
Copy link

fabich commented Apr 21, 2020

Hi all
I have a question regarding OpenApiPaths and their operations:
Let's assume I have the following two endpoints:

/api/mp/v1.0/order/{ordernumber}
/api/mp/v1.0/order/{id}

Is this valid from an OpenApi spec point of view?
According to online.swagger.io and OpenApiDiagnostic this is no issue.
Whey are they not combined? Or why is this not a validation issue?
With the following example from an API point of view I don't know what has been called:
/api/mp/v1.0/order/10

code to generate OpenApi spec:

        /// <summary>
        /// Gets the resource with the specified id.
        /// </summary>
        /// <param name="id">The resource id.</param>
        /// <response code="200">The resource with the specified id.</response>
        /// <response code="404">A resource with the specified id could not be found.</response>
        [HttpGet("{id}")]
        [Authorize(PolicyNames.OrderManagement.CanRead)]
        [ProducesResponseType(typeof(OrderReadDTO), StatusCodes.Status200OK)]
        [ProducesResponseType(typeof(BaseErrorResult), StatusCodes.Status404NotFound)]
        public async Task<IActionResult> GetById(int id)
        {
            var result = await _OrderService.GetSingleAsync(id);
            return new ObjectResult(result);
        }
        /// <summary>
        /// Gets the resource with the specified order number.
        /// </summary>
        /// <param name="orderno">The resource order number.</param>
        /// <response code="200">The resource with the specified order no.</response>
        /// <response code="404">A resource with the specified order no could not be found.</response>
        [HttpGet("{orderno}")]
        [Authorize(PolicyNames.OrderManagement.CanRead)]
        [ProducesResponseType(typeof(OrderReadDTO), StatusCodes.Status200OK)]
        [ProducesResponseType(typeof(BaseErrorResult), StatusCodes.Status404NotFound)]
        public async Task<IActionResult> GetByOrderNo(int orderno)
        {
            var result = await _OrderService.GetSingleAsync(orderno);
            return new ObjectResult(result);
        }
@darrelmiller
Copy link
Member

The current version of the OpenAPI specification says this scenario is invalid. http://spec.openapis.org/oas/v3.0.3#path-templating-matching

The following paths are considered identical and invalid:

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

This has been the case since the specification was created. This is one of the many challenges of trying to infer an OpenAPI specification from annotated code. The general consensus in the space is that explicitly creating the OpenAPI document as a design artifact up front is the best way to design APIs using OpenAPI.

There is a proposal on the table to introduce an priority property that would allow tooling to choose one operation over the other if there is ambiguity. I don't believe this would help the specific case you have shown.

@darrelmiller darrelmiller added the type:question An issue that's a question label Apr 26, 2020
@fabich
Copy link
Author

fabich commented Apr 27, 2020

thanks for your answer @darrelmiller

so shouldn't there be an error when loading a file like this in OpenApiDiagnostic?

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

I have no issue with this being invalid but the tooling is not reflecting this properly imho.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:question An issue that's a question
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants