Настройка конечной точки HTTP в Функциях Azure
Из этой статьи вы узнаете, как с помощью решения "Функции Azure" создавать API-интерфейсы с высоким уровнем масштабируемости. Функции Azure содержат набор встроенных триггеров и привязок HTTP, которые упрощают создание конечных точек на разных языках, включая Node.js, C# и другие. С помощью этой статьи вы настроите триггер HTTP, который будет обрабатывать определенные действия в вашем API. Вы также подготовите API к увеличению размеров, настроив интеграцию с Прокси-серверами Функций Azure и макеты API. Эти задачи выполняются в бессерверной вычислительной среде Функций, так что вам не придется беспокоиться о масштабировании ресурсов. Вы сможете полностью сосредоточиться на логике API.
Важно!
Функции Azure прокси-серверы — это устаревшая функция для версий 1.x–3.x среды выполнения Функции Azure. В версии 4.x можно повторно включить поддержку прокси-серверов, чтобы успешно обновить приложения-функции до последней версии среды выполнения. Как можно скорее переключитесь на интеграцию приложений-функций с Azure Управление API. Управление API позволяет воспользоваться преимуществами более полного набора функций для определения, защиты, администрации и монетизации API на основе Функций. Дополнительные сведения см. в статье интеграция Управление API.
Сведения о том, как повторно включить поддержку прокси-серверов в Функциях версии 4.x, см. в статье Повторное включение прокси-серверов в Функциях версии 4.x.
Предварительные требования
В этой статье в качестве отправной точки используются ресурсы, созданные при работе со статьей Создание первой функции на портале Azure. Выполните шаги в этой статье для создания приложения-функции, если вы еще не сделали этого.
Полученная функция будет использоваться в оставшейся части статьи.
Вход в Azure
Войдите на портал Azure с помощью своей учетной записи Azure.
Настройка функции HTTP
По умолчанию функция для триггера HTTP принимает любой метод HTTP. Можно также использовать стандартный URL-адрес http://<yourapp>.azurewebsites.net/api/<funcname>?code=<functionkey>
. В этом разделе вы измените функцию, чтобы она отвечала только на запросы GET по пути /api/hello
.
Перейдите к своей функции на портале Azure. В меню слева выберите Интеграция, а затем в разделе Триггер выберите HTTP (req) (HTTP (запрос)).
Используйте настройки триггера HTTP, указанные в следующей таблице.
Поле Образец значения Описание Шаблон маршрута hello Определяет пути, используемые для вызова этой функции Уровень авторизации Анонимные (Необязательно.) Предоставляет доступ к функции без ключа API Выбранные методы HTTP GET Разрешает использовать только выбранные методы HTTP для вызова этой функции Префикс базового пути
/api
не был включен в шаблон маршрута, так как он обрабатывается глобальным параметром.Нажмите кнопку Сохранить.
Дополнительные сведения о настройке функций HTTP см. в статье Обзорные сведения о триггерах и привязках HTTP в службе "Функции Azure".
Тестирование API
Протестируйте функцию и убедитесь, что она работает с новой контактной зоной API.
На странице функции в меню слева выберите Code + Test (Код + тестирование).
Щелкните Получить URL функции в меню сверху и скопируйте этот URL-адрес. Убедитесь, что теперь используется путь
/api/hello
.Скопируйте URL-адрес в новую вкладку браузера или в предпочтительный клиент REST.
Браузеры по умолчанию используют запросы GET.
Добавьте параметры в строку запроса в URL-адресе.
Например,
/api/hello/?name=John
.Нажмите клавишу ВВОД, чтобы проверить правильность работы. Вы увидите ответ "Hello John".
Вы также можете попытаться вызвать конечную точку с другим методом HTTP и убедиться, что функция при этом не выполняется. Для этого подойдет любой клиент REST, например cURL, Postman или Fiddler.
Общие сведения о прокси-серверах
В следующем разделе вы предоставите доступ к API через прокси-сервер. Функция "Прокси-серверы Функций Azure" позволяет вам перенаправлять запросы к другим ресурсам. Конечная точка HTTP определяется так же, как и триггер HTTP. Но вместо кода, который нужно выполнять при вызове конечной точки, здесь вы предоставляете URL-адрес удаленной реализации. Это позволяет объединить несколько источников API в одну удобную для клиентов контактную зону API, что очень полезно при разработке API в формате микрослужб.
Прокси-сервер может указывать на любой ресурс HTTP, например:
- Функции Azure
- Приложения API в службе приложений Azure.
- Контейнеры Docker в службе приложений под управлением Linux.
- Любой другой размещенный API.
Дополнительные сведения о прокси-серверах см. в статье Работа с функцией "Прокси-серверы Функций Azure".
Примечание
Прокси-серверы доступны в Функции Azure версий от 1.x до 3.x.
Создание первого прокси-сервера
В этом разделе вы создадите прокси-сервер, который будет играть роль интерфейса для вашего API.
Настройка среды интерфейса
Повторите шаги для создания приложения-функции, чтобы создать приложение-функцию, в котором вы создадите свой прокси-сервер. URL-адрес этого нового приложения будет использоваться в качестве интерфейсного URL-адреса для API, а измененное приложение-функция станет его внутренней частью.
Перейдите к своему новому приложению-функции интерфейса на портале.
Выберите Конфигурация, а затем — Параметры приложения.
Прокрутите вниз до раздела Параметры приложения, в котором хранятся пары "ключ — значение", а затем создайте параметр с ключом
HELLO_HOST
. Задайте узел приложения-функции внутреннего сервера, например<YourBackendApp>.azurewebsites.net
, в качестве его значения. Это значение содержит часть URL-адреса, который вы скопировали ранее при тестировании функции HTTP. Вы укажете этот параметр при конфигурации позднее.Примечание
Мы рекомендуем использовать параметры приложения для настройки узла, чтобы прокси-сервер не зависел от жестко заданной среды. Использование настроек приложения означает, что вы можете перемещать конфигурацию прокси-сервера между средами. Параметры приложения для конкретной среды будут применяться.
Нажмите кнопку Сохранить.
Создание прокси-сервера в интерфейсе
Вернитесь к разделу портала для интерфейсного приложения-функции.
В меню слева выберите Прокси-серверы, а затем щелкните Добавить.
На странице Новый прокси-сервер примените параметры из следующей таблицы, а затем щелкните Создать.
Поле Образец значения Описание Имя HelloProxy Понятное имя, используемое только для управления Шаблон маршрута /api/remotehello Определяет пути, используемые для вызова этого прокси-сервера Внутренний URL-адрес https://%HELLO_HOST%/api/hello Определяет конечную точку, к которой должен быть отправлен запрос Прокси-серверы Функций Azure не предоставляют префикс базового пути
/api
, поэтому его нужно включить в шаблон маршрутов. Синтаксис%HELLO_HOST%
ссылается на созданный ранее параметр приложения. Разрешенный URL-адрес будет указывать на исходную функцию.Проверьте работу нового прокси-сервера, скопировав URL-адрес прокси-сервера и вставив его в адресную строку в браузере или в любой клиент HTTP.
- Для анонимной функции используйте адрес
https://YOURPROXYAPP.azurewebsites.net/api/remotehello?name="Proxies"
. - Для функции с авторизацией используйте адрес
https://YOURPROXYAPP.azurewebsites.net/api/remotehello?code=YOURCODE&name="Proxies"
.
- Для анонимной функции используйте адрес
Создание макета API
Теперь вы создадите для своего решения макет API на основе прокси-сервера. Прокси-сервер позволяет разрабатывать клиент, не дожидаясь полнофункциональной реализации серверной службы. На следующих этапах разработки вы сможете создать приложение-функцию, которое поддерживает эту логику, и перенаправить на него прокси-сервер.
Чтобы создать макет API, мы создадим прокси-сервер, в этот раз с помощью Редактора службы приложений. Чтобы начать работу, перейдите к своему приложению-функции на портале. Выберите Функции платформы и в разделе Средства разработки найдите Редактор службы приложений. Редактор службы приложений откроется в новой вкладке.
В левой области навигации выберите proxies.json
. Этот файл содержит конфигурацию всех прокси-серверов. Если вы используете любой метод развертывания функций, этот файл хранится в системе управления версиями. Дополнительные сведения об этом файле см. в разделе Расширенная конфигурация.
Если вы выполнили все указания пошагового руководства, то файл proxies.json должен выглядеть следующим образом:
{
"$schema": "http://json.schemastore.org/proxies",
"proxies": {
"HelloProxy": {
"matchCondition": {
"route": "/api/remotehello"
},
"backendUri": "https://%HELLO_HOST%/api/hello"
}
}
}
Теперь добавьте в него макет API. Замените весь текст в файле proxies.json следующим кодом:
{
"$schema": "http://json.schemastore.org/proxies",
"proxies": {
"HelloProxy": {
"matchCondition": {
"route": "/api/remotehello"
},
"backendUri": "https://%HELLO_HOST%/api/hello"
},
"GetUserByName" : {
"matchCondition": {
"methods": [ "GET" ],
"route": "/api/users/{username}"
},
"responseOverrides": {
"response.statusCode": "200",
"response.headers.Content-Type" : "application/json",
"response.body": {
"name": "{username}",
"description": "Awesome developer and master of serverless APIs",
"skills": [
"Serverless",
"APIs",
"Azure",
"Cloud"
]
}
}
}
}
}
Этот код добавляет новый прокси-сервер GetUserByName
без свойства backendUri
. Вместо вызова другого ресурса он изменяет ответ по умолчанию от прокси-серверов, используя переопределение ответа. Переопределение запроса и ответа может также использоваться с URL-адресом внутреннего сервера. Эта методика полезна при перенаправлении к устаревшим системам, где иногда нужно менять заголовки, параметры запроса и т. д. Дополнительные сведения о переопределении запроса и ответа см. в этой статье.
Протестируйте макет API, вызвав конечную точку <YourProxyApp>.azurewebsites.net/api/users/{username}
с помощью браузера или избранного клиента REST. Замените {username} строковым значением, представляющим имя пользователя.
Дальнейшие действия
Из этой статьи вы узнали, как создать и настроить API с помощью решения "Функции Azure", а также объединять несколько API, включая макеты, в единую поверхность API. Вы можете использовать эти методы для создания API любой сложности, работая в бессерверной вычислительной модели, предоставляемой Функциями Azure.
Следующие ссылки могут оказаться полезными при дальнейшей разработке API: