Настройка конечной точки 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.

  1. Перейдите к своей функции на портале Azure. В меню слева выберите Интеграция, а затем в разделе Триггер выберите HTTP (req) (HTTP (запрос)).

    Настройка функции HTTP

  2. Используйте настройки триггера HTTP, указанные в следующей таблице.

    Поле Образец значения Описание
    Шаблон маршрута hello Определяет пути, используемые для вызова этой функции
    Уровень авторизации Анонимные (Необязательно.) Предоставляет доступ к функции без ключа API
    Выбранные методы HTTP GET Разрешает использовать только выбранные методы HTTP для вызова этой функции

    Префикс базового пути /api не был включен в шаблон маршрута, так как он обрабатывается глобальным параметром.

  3. Нажмите кнопку Сохранить.

Дополнительные сведения о настройке функций HTTP см. в статье Обзорные сведения о триггерах и привязках HTTP в службе "Функции Azure".

Тестирование API

Протестируйте функцию и убедитесь, что она работает с новой контактной зоной API.

  1. На странице функции в меню слева выберите Code + Test (Код + тестирование).

  2. Щелкните Получить URL функции в меню сверху и скопируйте этот URL-адрес. Убедитесь, что теперь используется путь /api/hello.

  3. Скопируйте URL-адрес в новую вкладку браузера или в предпочтительный клиент REST.

    Браузеры по умолчанию используют запросы GET.

  4. Добавьте параметры в строку запроса в URL-адресе.

    Например, /api/hello/?name=John.

  5. Нажмите клавишу ВВОД, чтобы проверить правильность работы. Вы увидите ответ "Hello John".

  6. Вы также можете попытаться вызвать конечную точку с другим методом HTTP и убедиться, что функция при этом не выполняется. Для этого подойдет любой клиент REST, например cURL, Postman или Fiddler.

Общие сведения о прокси-серверах

В следующем разделе вы предоставите доступ к API через прокси-сервер. Функция "Прокси-серверы Функций Azure" позволяет вам перенаправлять запросы к другим ресурсам. Конечная точка HTTP определяется так же, как и триггер HTTP. Но вместо кода, который нужно выполнять при вызове конечной точки, здесь вы предоставляете URL-адрес удаленной реализации. Это позволяет объединить несколько источников API в одну удобную для клиентов контактную зону API, что очень полезно при разработке API в формате микрослужб.

Прокси-сервер может указывать на любой ресурс HTTP, например:

Дополнительные сведения о прокси-серверах см. в статье Работа с функцией "Прокси-серверы Функций Azure".

Примечание

Прокси-серверы доступны в Функции Azure версий от 1.x до 3.x.

Создание первого прокси-сервера

В этом разделе вы создадите прокси-сервер, который будет играть роль интерфейса для вашего API.

Настройка среды интерфейса

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

  1. Перейдите к своему новому приложению-функции интерфейса на портале.

  2. Выберите Конфигурация, а затем — Параметры приложения.

  3. Прокрутите вниз до раздела Параметры приложения, в котором хранятся пары "ключ — значение", а затем создайте параметр с ключом HELLO_HOST. Задайте узел приложения-функции внутреннего сервера, например <YourBackendApp>.azurewebsites.net, в качестве его значения. Это значение содержит часть URL-адреса, который вы скопировали ранее при тестировании функции HTTP. Вы укажете этот параметр при конфигурации позднее.

    Примечание

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

  4. Нажмите кнопку Сохранить.

Создание прокси-сервера в интерфейсе

  1. Вернитесь к разделу портала для интерфейсного приложения-функции.

  2. В меню слева выберите Прокси-серверы, а затем щелкните Добавить.

  3. На странице Новый прокси-сервер примените параметры из следующей таблицы, а затем щелкните Создать.

    Поле Образец значения Описание
    Имя HelloProxy Понятное имя, используемое только для управления
    Шаблон маршрута /api/remotehello Определяет пути, используемые для вызова этого прокси-сервера
    Внутренний URL-адрес https://%HELLO_HOST%/api/hello Определяет конечную точку, к которой должен быть отправлен запрос

    Создание прокси

    Прокси-серверы Функций Azure не предоставляют префикс базового пути /api, поэтому его нужно включить в шаблон маршрутов. Синтаксис %HELLO_HOST% ссылается на созданный ранее параметр приложения. Разрешенный URL-адрес будет указывать на исходную функцию.

  4. Проверьте работу нового прокси-сервера, скопировав 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: