As an HTTP API developer using Open API to enable integration, my APIs include an opinionated convention of ensuring operationId attributes are created for each Web API controller method

[bradygaster]

One of the more important concepts in the OpenAPI Specification is the concept of operationId. Each API method’s descriptive metadata can be augmented with operationId to provide code generations and consumers with a cleaner API for consumers to use.

When we speak of a consumer, we’re speaking of a variety of code-generation and endpoint-parsing tools that make use of the OpenAPI spec to generate code or UI. AutoRest, swagger-codegen, NSwag, and SwaggerHub - all products used throughout the API community to either generate client SDK code to call an API or to provide documentation about an API – they all prioritize operationId, as do our partners in the Power Platform, when using Open API files or API Management-hosted APIs to provide citizen developers easy ways of dialing APIs into their Power Apps.

Our Controller templates don't explicitly name each method. As such, code generators and consumers need to "guess" what to name the generated code methods. This results in odd situations where client SDKs have methods like get, get1, get2, and so on.

Existing controller method syntax:

[HttpGet]
public IEnumerable<WeatherForecast> Get()

Desired syntax:

[HttpGet(Name = nameof(Get))]
public IEnumerable<WeatherForecast> Get()

[carlossanlop]

Should this issue be in the ASP.NET repo?

[bradygaster]

adding @mkArtakMSFT and @pranavkm to see if it should be.

[pranavkm]

Thanks @bradygaster. Do you see a system where we require users to specify this name if they have Swagger / ApiExplorer enabled in their apps? Or is this more of a guidance that recommends people name their operations?

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[bradygaster]

@mkArtakMSFT @javiercn - definitely need this to help developers on the right operationId path.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[adityamandaleeka]

Triage: moving to backlog

[rafikiassumani-msft]

@bradygaster can we close this issue? OperationId work was part of .NET6. Any further improvement ?

[ghost]

Hi @bradygaster. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.

[bradygaster]

Yes this can be closed. I'll close it. :)