[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-api-gateway::ru":3,"gloss-cluster-api-gateway::ru":20,"gloss-next-api-gateway::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"api-gateway","dev-tools","API-шлюз (API Gateway)","API-шлюз — это сервер, стоящий перед одним или несколькими бэкенд-сервисами и выступающий единой точкой входа для всего API-трафика, централизованно решая сквозные задачи вместо дублирования этой логики в каждом отдельном сервисе. Типичные обязанности включают маршрутизацию запросов (отправку `\u002Fusers\u002F*` в сервис пользователей, а `\u002Forders\u002F*` — в сервис заказов), аутентификацию и авторизацию (проверку API-ключей или JWT до того, как запрос вообще достигнет бэкенда), ограничение частоты запросов (блокировку клиента, превысившего квоту), преобразование запросов\u002Fответов и централизованное логирование и мониторинг. Популярные реализации варьируются от управляемых облачных сервисов (AWS API Gateway, Azure API Management) до опенсорсных\u002Fself-hosted решений (Kong, Tyk, Apache APISIX) и встроенного слоя API-шлюза в большинстве современных serverless- и edge-платформ. Почему это важно для разработчиков AI\u002FSaaS: API-шлюз особенно критичен, когда у SaaS-продукта появляется несколько бэкенд-сервисов (микросервисная архитектура) или он хочет предоставить публичный API сторонним разработчикам, поскольку централизует политику безопасности и ограничения частоты запросов в одном месте, а не полагается на то, что каждый отдельный сервис реализует их правильно и согласованно. Это также естественное место для реализации монетизации API (учёт использования по API-ключу для биллинга) и для защиты именно AI-эндпоинтов от злоупотреблений, поскольку вызовы LLM API стоят гораздо дороже в расчёте на запрос по сравнению с типичными CRUD-эндпоинтами. Как это работает: каждый входящий запрос сначала попадает на шлюз. Шлюз проверяет запрос по настроенным правилам — валиден ли API-ключ? не превысил ли клиент лимит частоты запросов? допускает ли область действия JWT это действие? — и только если все проверки пройдены, перенаправляет (проксирует) запрос в соответствующий бэкенд-сервис, часто добавляя заголовки, идентифицирующие аутентифицированного клиента. Ответ бэкенда проходит обратно через шлюз, который может залогировать его, преобразовать или закэшировать перед возвратом исходному вызывающему. Практический пример: SaaS-компания запускает публичный API для сторонних разработчиков, позволяющий запрашивать данные аналитики, с оплатой за каждую 1000 запросов. Каждый вызов `api.example.com\u002Fv1\u002Fanalytics` сначала попадает на их API-шлюз. Шлюз проверяет API-ключ вызывающего по базе данных, убеждается, что он не превысил месячную квоту своего тарифа (скажем, 100 000 запросов), увеличивает счётчик использования для биллинга и только после этого перенаправляет сам запрос во внутренний сервис аналитики — которому вообще не приходится реализовывать аутентификацию или ограничение частоты запросов, поскольку шлюз уже гарантировал, что до него доходят только валидные запросы в рамках квоты. Если вызывающий превышает квоту, сам шлюз возвращает `429 Too Many Requests`, даже не затрагивая внутренний сервис.","API-шлюз — единая точка входа, которая маршрутизирует, аутентифицирует, ограничивает и управляет трафиком к бэкенд-сервисам и API системы.",null,[11,14,17],{"slug":12,"name":13},"edge-function","Edge-функция (Edge Function)",{"slug":15,"name":16},"sdk","Набор средств разработки (SDK)",{"slug":18,"name":19},"serverless","Бессерверные вычисления (Serverless)",[21,25,28,32,35,38,41,44,47,50,53,56],{"slug":22,"category":5,"name":23,"updated_at":24},"agent","Агент (Agent)","2026-08-24T02:46:36+00:00",{"slug":26,"category":5,"name":27,"updated_at":24},"ai-code-assistant","AI-помощник по написанию кода",{"slug":29,"category":5,"name":30,"updated_at":31},"api-versioning","API Versioning (версионирование API)","2026-08-24T02:46:37+00:00",{"slug":33,"category":5,"name":34,"updated_at":24},"autonomous-agent","Автономный агент (Autonomous Agent)",{"slug":36,"category":5,"name":37,"updated_at":31},"blue-green-deployment","Blue-Green Deployment (сине-зелёное развёртывание)",{"slug":39,"category":5,"name":40,"updated_at":31},"canary-deployment","Canary Deployment (канареечное развёртывание)",{"slug":42,"category":5,"name":43,"updated_at":31},"chaos-engineering","Chaos Engineering (хаос-инжиниринг)",{"slug":45,"category":5,"name":46,"updated_at":24},"ci-cd","Непрерывная интеграция \u002F непрерывное развёртывание (CI\u002FCD)",{"slug":48,"category":5,"name":49,"updated_at":31},"circuit-breaker","Предохранитель (Circuit Breaker)",{"slug":51,"category":5,"name":52,"updated_at":31},"cli","Интерфейс командной строки (CLI)",{"slug":54,"category":5,"name":55,"updated_at":31},"cloud-development-environment","Облачная среда разработки (CDE)",{"slug":57,"category":5,"name":58,"updated_at":24},"code-completion","Дополнение кода (Code Completion)"]