Управление API Azure. Различение операций по параметрам пути и запроса

Question

У меня есть бэкэнд API (который реализует ApiController ), который я хотел бы оставить за API APIM.ApiController позволяет нам различать две различные операции GET на основе параметров запроса, которые передаются. Когда я пытаюсь определить эти конечные точки в APIM, я получаю следующую ошибку:

В сообщении предлагается, что конечная точка определяется исключительно путем и операцией.Но это, кажется, противоречит документации, которую я нашел здесь , в которой предлагается способ дифференциации операций на основе параметров запроса:

Обязательные параметры как для пути, так и для запроса должны иметь уникальные имена.(В OpenAPI имя параметра должно быть уникальным только в пределах местоположения, например, путь, запрос, заголовок. Однако в API-управлении мы разрешаем распознавать операции как по параметрам пути, так и по параметрам запроса (чего не делает OpenAPIне поддерживается.) Именно поэтому мы требуем, чтобы имена параметров были уникальными во всем шаблоне URL.)

У меня есть ApiController, который определяет две разные операции Get, отличающиеся только параметрами запроса.Как мне представить это в моем API APIM?

Answer 1

Я получил ответ от службы поддержки Azure, поделившись информацией здесь:

Конечные точки APIM определяются путем, методом и именем, которое вы назначаете для операции.Чтобы различать две конечные точки GET для одного и того же контроллера, отличающиеся только параметрами запроса, необходимо жестко закодировать требуемые параметры запроса в пути.См. Следующие два изображения:

На последнем изображении это жестко закодированный запросПараметр классифицируется пользовательским интерфейсом как параметр шаблона, но он по-прежнему ведет себя как обычный параметр запроса.Аргументы запроса, определенные следующим образом:

• Требуются
• Может появляться в любом месте списка аргументов запроса в запросе
• Не чувствительны к регистру
• Перечислены в качестве «параметра запроса» вместе со всеми другими параметрами пути и аргументами запроса на портале разработки

Редактировать:

Существует опечатка вскриншоты.URL-адреса чувствительны к регистру, и в каждом случае регистр «бла» был разным.Вот как выглядит спецификация Open API, когда корпус согласован.Перегруженный путь (с параметром запроса, жестко запрограммированным в шаблоне пути) появляется в разделе с именем x-ms-paths:

{
    "swagger": "2.0",
    "info": {
        "title": "Echo API",
        "version": "1.0"
    },
    "host": "<hostUrl>",
    "basePath": "/echo",
    "schemes": ["https"],
    "securityDefinitions": {
        "apiKeyHeader": {
            "type": "apiKey",
            "name": "Ocp-Apim-Subscription-Key",
            "in": "header"
        },
        "apiKeyQuery": {
            "type": "apiKey",
            "name": "subscription-key",
            "in": "query"
        }
    },
    "security": [{
        "apiKeyHeader": []
    }, {
        "apiKeyQuery": []
    }],
    "paths": {
        "/Blah": {
            "get": {
                "operationId": "blah",
                "summary": "Blah",
                "responses": {}
            }
        }
    },
    "tags": [],
    "x-ms-paths": {
        "/Blah?alpha={alpha}": {
            "get": {
                "operationId": "blah2",
                "summary": "Blah2",
                "parameters": [{
                    "name": "alpha",
                    "in": "query",
                    "required": true,
                    "type": "string"
                }],
                "responses": {}
            }
        }
    }
}

Answer 2

Проблема связана с несколькими объектами операций с одинаковым OperationId.Это неверное чванство.В файле Swagger не совпадает имя выбранного API, поэтому измените атрибут title тега doc, чтобы он соответствовал целевому API, с которым он работал.

Вот аналогичный SO поток Вы могли бы обратиться к.