Бессерверная перспектива шлюза HTTP API

Давайте посмотрим на различия между REST и HTTP; Стоимость HTTP API Gateway, интеграция и мониторинг.

Что такое шлюз HTTP API?

Еще в те дни, когда AWS выпустила первую версию API Gateway, они пытались сделать его более высоким уровнем, чем фаланга балансировщиков нагрузки, которые они уже предлагали. Он не требует сервера и использует подход RESTful к моделированию API, позволяя пользователям использовать спецификацию OpenAPI для определения своих API.

Хотя REST — отличный подход для большинства API, он подходит не всем, а также в сервисе отсутствовали веб-сокеты. Это означало, что людям приходилось либо использовать REST и без WebSockets, когда они хотели бессерверный прокси, либо они должны были использовать балансировщик нагрузки приложений, который был более низкоуровневым, но не бессерверным.

Именно из-за этих недостатков была создана новая версия API-шлюза, названная HTTP-шлюзом API или API-шлюзом V2. Он поставляется с теми же бессерверными преимуществами, что и автоматическое масштабирование и цена по требованию, но предлагает поддержку WebSocket и не привязан к дизайну REST API.

Инфографика AWS HTTP Gateway от Dashbird

REST против HTTP

REST — это парадигма дизайна API, созданная Роем Филдингом. Его цель состояла в том, чтобы дать людям инструмент для разработки API поверх HTTP без всех проблем, которые были у других парадигм, таких как SOAP, в прошлом. Таким образом, REST пытается формализовать HTTP, чтобы сделать его более удобным для использования в случаях использования API.

В свою очередь HTTP более гибок; есть и другие способы создания API на HTTP, которые не соответствуют подходу REST. К ним относятся AsyncAPI и GraphQL. В отличие от REST, у них разные взгляды на дизайн конечных точек и использование WebSockets для обеспечения взаимодействия в реальном времени.

Итак, если вы создаете простой CRUD API, вы можете сэкономить много времени, просто используя REST API Gateway. Но если вам нужно быть более гибким, используйте HTTP-версию, но имейте в виду, что она поставляется с меньшей помощью из коробки.

Стоимость шлюза HTTP API

API Gateway имеет 12-месячный уровень бесплатного пользования. Это включает следующие лимиты на каждый месяц:

• один миллион вызовов REST API

• один миллион вызовов HTTP API

• один миллион сообщений WebSocket API

• 750 000 минут подключения к WebSocket API

За первые 300 миллионов запросов после уровня бесплатного пользования вы платите 1 доллар США за миллион; после этого 0,90 доллара.

За первый миллиард (да, миллиард) сообщений WebSocket вы также платите 1 доллар за миллион; после этого 0,80 доллара за следующий миллион.

Таким образом, HTTP API Gateway немного дешевле, чем версия REST, которая стоит около 3,50 долларов США за миллион запросов.

Сервисные интеграции

Возможности интеграции шлюза HTTP API также немного ограничены. В то время как REST API предлагает прямую интеграцию с десятками сервисов AWS, версия HTTP предлагает только интеграцию Lambda и HTTP. Это означает, что если вы не хотите интегрироваться с Lambda, ваша нижестоящая служба должна предоставить HTTP API.

Интеграция Lambda — это решение одним щелчком мыши для сопоставления маршрута с функцией Lambda; он будет автоматически пересылать заголовки, тело, параметры запроса и т. д. Lambda рассматривается как серверная часть по умолчанию для бессерверных приложений, поэтому AWS максимально упростила его настройку.

HTTP — универсальное решение. Если вы хотите передать свои запросы другому сервису, HTTP API Gateway просто проксирует его через HTTP. К счастью, вы можете убедиться, что подчиненный сервис получает необходимую ему информацию с помощью сопоставления параметров.

Авторизация

Шлюз HTTP API позволяет авторизовать пользователей для ваших API с помощью веб-токенов JSON или лямбда-функции авторизатора, которая будет вызываться вместе с каждым запросом. Это может стать довольно дорогим; поэтому ответ Lambda можно кэшировать. Все это можно настроить; для некоторых API кэширование авторизации невозможно по соображениям безопасности; для других это может не представлять проблемы.

Функция Lambda может возвращать либо простое логическое значение, true для «имеет доступ» и false для «не имеет доступа», либо документ IAM, в котором более подробно рассказывается о том, что разрешено делать клиенту. Это позволяет добавить функции авторизации во все ваши HTTP-серверы всего за несколько кликов.

Миграция с REST на HTTP

Весь подход HTTP более гибкий и, что, наверное, самое интересное, намного дешевле, чем REST. Одного этого, возможно, достаточно, чтобы перейти от версии REST.

Но вещи между ними достаточно разные, поэтому перед этим вам следует обратиться к руководству по миграции. Веб-консоль выглядит иначе; CloudFormation требует от вас использования других ресурсов, интеграция Lambda работает по-другому и т. д.

Так что, к сожалению, это не просто увеличение номера версии, добавление HTTP-переключателя, и дело сделано. Но люди уже написали несколько статей об этой миграции и ее подводных камнях. Ознакомьтесь с этим превосходным руководством по миграции от Serverless Guru, чтобы разобраться во всем. .

Мониторинг шлюза HTTP API с помощью Dashbird

В прошлом месяце Dashbird [выпустил большое обновление] (https://dashbird.io/blog/dashbird-now-integrates-with-5-new-aws-services/), включающее дополнительные сервисы для мониторинга. HTTP API Gateway — один из них. Исторически API Gateway была одной из самых дорогих частей бессерверных архитектур, и теперь с новым обновлением Dashbirds вы можете получить эти сладкие сбережения, сохраняя при этом понимание.

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

Dashbird показывает текущие ошибки и предупреждает, когда процент ошибок достигает критического уровня. Сюда входят ошибки HTTP 4XX и 5XX.

Вы также получаете информацию о задержке с течением времени и уведомления, если она увеличивается или вот-вот истечет время ожидания.

И последнее, но не менее важное: вы получаете уведомления о заброшенных шлюзах. То есть шлюзы, которые вы развернули в облаке, но которые больше не используются.

Заключение

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

Но интеграция со шлюзом HTTP API ограничена службами HTTP, что снова снижает гибкость. Если вы видите, что дюжины размещаете функции Lambda между вашим шлюзом и вашими службами, вы можете не сэкономить деньги и без необходимости увеличивать сложность своего стека. Именно тогда вы можете лучше обслуживать шлюз REST API, который предлагает более дешевую интеграцию с другими сервисами AWS.