Creating an API from OpenAPI specification results in false "duplicate signature" error.

Question

The bug

When importing the following OpenApi spec with the OpenApi importer in Azure Api Management, an error is returned:

'Importing API has duplicate signature operations: 2 operations with signature 'GET /api/group-users/{id}'

Reproduction

Steps to reproduce the behavior:

1. Go to Azure Api Management in portal.azure.com
2. Click on Apis
3. Click on Add Api
4. Click on Create definition from OpenAPI
5. Use the following OpenApi spec:

{
    "x-generator": "NSwag v14.0.2.0 (NJsonSchema v11.0.0.0 (Newtonsoft.Json v13.0.0.0))",
    "openapi": "3.0.0",
    "info": {
      "title": "Test web API",
      "description": "Test web API",
      "version": "1.0.0"
    },
    "servers": [
      {
        "url": "https://testwebapi.com"
      }
    ],
    "paths": {
      "/api/group-users/{id}": {
        "get": {
          "tags": [
            "GroupUsers"
          ],
          "operationId": "GroupUsers_GetById",
          "parameters": [
            {
              "name": "id",
              "in": "path",
              "required": true,
              "schema": {
                "type": "integer",
                "format": "int32"
              },
              "x-position": 1
            }
          ],
          "responses": {
            "200": {
              "description": "",
              "content": {
                "application/json": {
                  "schema": {
                    "$ref": "#/components/schemas/groupUser"
                  }
                }
              }
            },
          }
          }
        },
      "/api/group-users/{guidId}": {
        "get": {
          "tags": [
            "GroupUsers"
          ],
          "operationId": "GroupUsers_GetByguidId",
          "parameters": [
            {
              "name": "guidId",
              "in": "path",
              "required": true,
              "schema": {
                "type": "string",
                "format": "guid"
              },
              "x-position": 1
            }
          ],
            "responses": {
            "200": {
              "description": "",
              "content": {
                "application/json": {
                  "schema": {
                    "$ref": "#/components/schemas/groupUser"
                  }
                }
              }
            }
          }
          }
        }
      },
    "components": {
      "schemas": {
            "groupUser": {
              "readOnly": true,
              "nullable": true,
              "oneOf": [
                {
                  "$ref": "#/components/schemas/GroupUser"
                }
              ]
            },"GroupUser": {
          "type": "object",
          "additionalProperties": false,
          "properties": {
            "id": {
              "type": "integer",
              "readOnly": true,
              "format": "int32"
            }
          }
        },
          }
      }
  }

Expected behavior

I expect the Import to succeed. There isn't a duplicate endpoint. While the definition is the same, it differs in datatype and OperationId. This is a valid open API spec.

It seems to me that this is an actual bug in the import function, but any suggestions are greatly appreciated

Answer 1

Hello @jessy visch !

Welcome to Microsoft QnA!

The issue you're encountering in Azure API Management when importing an OpenAPI specification is related to how API Management distinguishes different operations. Azure API Management uses a combination of the HTTP method and the URL path to identify unique operations. In your case, the two operations have the same HTTP method (GET) and the URL path (/api/group-users/{parameter}), even though they have different path parameter names (id and guidId) and types.

Azure API Management doesn't distinguish between different path parameters when they are in the same position in the URL. It treats /api/group-users/{id} and /api/group-users/{guidId} as the same operation because it sees them both as /api/group-users/{parameter}.

To resolve this issue:

1. Modify the Paths: You need to make the paths distinct in a way that Azure API Management can recognize. This often means changing the actual URL structure. For example:

      jsonCopy code
      "/api/group-users/by-id/{id}":
      
   

2. Operation Overloading: If you cannot modify the paths (for instance, if they are already established and used by clients), you might need to consider operation overloading in a single endpoint. This would involve handling the logic of differentiating between id and guidId within the same operation, based on their formats.

So adjusting the URL paths as described above is a common workaround for this limitation. This approach requires changes to your API design, but it ensures compatibility with Azure API Management's operation identification mechanism.

--

I hope this helps!

The answer or portions of it may have been assisted by AI Source: ChatGPT Subscription

Kindly mark the answer as Accepted and Upvote in case it helped or post your feedback to help !

Regards