Эндпоинты REST API на функциях за API-шлюзом
Публикуйте JSON API без монолитного роутера: группируйте эндпоинты, которые меняются вместе, держите авторизацию на API-шлюзе, задавайте CORS и лимиты централизованно и версионируйте пути до ломающих изменений схемы.
Обновлено: 2026-06-28
Кратко
Суть ответа
Эндпоинты REST API на функциях за API-шлюзом. Группируйте REST-эндпоинты, которые деплоятся вместе; авторизацию, CORS и лимиты по возможности держите на API-шлюзе.
Когда подходит
- Внутренние API
- Интеграции с партнёрами
- Мультитенантные B2B-поверхности
На что обратить внимание
- Десятки крошечных репозиториев и пайплайнов создают расползание — командам всё равно нужны общие авторизация, CORS и лимиты для публичных JSON API.
Нагрузка и где ломается
Почему монолитный REST-роутер замедляет команду
Связывание несвязанных эндпоинтов в один деплой затрудняет поиск причины инцидента и замедляет выпуск изменений.
Масштабировать весь бинарник ради одного нагруженного маршрута — лишняя память, когда всплеск приходится на узкий срез JSON API.
Когда простых рецептов недостаточно
Почему дробление только на микросервисы тоже мимо
Десятки крошечных репозиториев и пайплайнов создают расползание — командам всё равно нужны общие авторизация, CORS и лимиты для публичных JSON API.
Как помогает Inquir
Группы маршрутов на кластер функций
Группируйте REST-эндпоинты, которые деплоятся вместе; авторизацию, CORS и лимиты по возможности держите на API-шлюзе.
Валидируйте на границе обработчика и используйте префиксы путей для версионирования до ломающих изменений JSON-контрактов.
Что вы получаете
Гигиена REST API на шлюзе
Лимиты запросов
Задавайте лимиты на шлюзе, чтобы злоупотребляющие или вышедшие из-под контроля клиенты не исчерпали общие зависимости.
CORS
Настраивайте CORS явно на шлюзе, чтобы браузерные клиенты работали без кода заголовков в каждом обработчике.
Версионирование
Вводите префиксы путей до того, как отправите ломающие изменения в публичные JSON-контракты.
Что дальше
Как выставлять REST API из функций Inquir
Спроектировать карту ресурсов
Моделируйте ресурсы существительными и стандартизируйте единый формат ошибок для всех маршрутов.
Реализовать обработчики
Валидируйте вход на границе обработчика, чтобы плохие payload падали быстро и с единообразной ошибкой.
Нагрузочный тест
Замеряйте параллелизм по каждому маршруту, а не только суммарный RPS.
Пример кода
Хелпер для JSON-ошибок
Единый формат ошибок упрощает клиентские SDK. Пример конверта: запрос GET /v1/users/42 → ответ { "error": { "code": "not_found", "message": "User not found" } }.
export function jsonError(status, code, message) { return { statusCode: status, body: JSON.stringify({ error: { code, message } }) }; }
Когда подходит
Когда подходит
Когда это уместно
- Внутренние API
- Интеграции с партнёрами
- Мультитенантные B2B-поверхности
Когда лучше выбрать другое
- Монолит на фреймворке уже работает, а команда совсем маленькая
Частые вопросы
Частые вопросы
Можно ли выставить GraphQL из функции?
Да — одна функция может держать схему и резолверы; лимиты, авторизация и холодные/тёплые старты по-прежнему действуют на уровне шлюза.
Насколько мелкой должна быть каждая REST-функция?
Группируйте маршруты, которые деплоятся и падают вместе; отдельная функция на каждый путь может взорвать операционный шум — ищите баланс, который команда сможет поддерживать.
Где живут проверка API-ключей и JWT?
По возможности используйте хуки авторизации на уровне шлюза: обработчики получают уже проверенный контекст и остаются простыми в тестировании.