[Feature Request] Standardize operationIds to ensure uniqueness

[peombwa]

We should consider standardizing the naming convention of operationIds to what we currently have in DevX API (PowerShell style) - https://github.com/microsoftgraph/microsoft-graph-devx-api/blob/dev/OpenAPIService/PowershellFormatter.cs? For example:

• Remove hash suffix values from operationIds for function all paths.
• Add '_' to separate verb (action) in an operationId. This typically the last . or second from last . for OData cast paths.
• PUT operations should have Set as the verb in an operationId {xxx}_Set{yyy}.

In PowerShell, we use operationIds to form command names.

As part of this exercise, we should add validation to ensure operationIds are unique for a given document.

Edit: This is a continuation of #338 (comment).

[irvinesunday]

I like this:

As part of this exercise, we should add validation to ensure operationIds are unique for a given document.

@peombwa I have a few questions on this:

1. Are there other clients (outside of AutoREST dependent clients) that are already using the current format that would be impacted by this change?
2. The clients referred to in your comment, are they using this library directly?

[peombwa]

1. Are there other clients (outside of AutoREST dependent clients) that are already using the current format that would be impacted by this change?

Not that I’m aware of. All Microsoft Graph OpenAPI-based SDKs use paths and operation names to construct request builders/command names except for PowerShell, which uses AutoREST. AutoREST uses operationIds to construct command names; uniqueness is key. If a breaking change is a concern, I think it’s best to assume that there is probably a tool out there that takes a dependency on the current OperationId naming convention.

2. The clients referred to in your comment, are they using this library directly?

This is based on a customer comment in the metadata repo at microsoftgraph/msgraph-metadata#289:

I was attempting to use an existing openapi parser (Azure Autorest) to build a client for the graph yaml, and it generates ~40 errors due to duplicate operationId values.

Based on the customer issue, they are using the OpenAPI YAML file in the metadata repo that’s generated using this library.

[irvinesunday]

If a breaking change is a concern, I think it’s best to assume that there is probably a tool out there that takes a dependency on the current OperationId naming convention.

@peombwa based on this concern, can we put a hold on this request?