API (REST, gRPC, GraphQL)

API (англ. Application Programming Interface, программный интерфейс приложения) — это набор правил и протоколов, с помощью которого одна компьютерная программа может взаимодействовать с другой, запрашивая данные или выполняя действия. API определяет, как именно разработчики могут обращаться к функциям, сервисам или ресурсам другой программы, абстрагируя её внутреннее устройство. В современной веб-разработке и распределённых системах наиболее распространены три архитектурных стиля API: REST, gRPC и GraphQL, каждый из которых имеет свои принципы, преимущества и области применения.

История и предпосылки появления

До широкого распространения API взаимодействие между программами было жёстко привязано к конкретным языкам программирования, платформам или операционным системам. С развитием интернета и веб-сервисов в конце 1990-х — начале 2000-х годов возникла потребность в универсальных, платформонезависимых способах обмена данными. Первым массовым стандартом стал SOAP (Simple Object Access Protocol), основанный на XML и строгих контрактах (WSDL). Однако его сложность и громоздкость привели к появлению более лёгких альтернатив.

В 2000 году Рой Филдинг в своей диссертации сформулировал принципы архитектурного стиля REST (Representational State Transfer). REST стал доминирующим подходом для веб-API благодаря своей простоте, использованию HTTP-методов и форматов данных (JSON, XML). В 2015 году компания Facebook (организация признана экстремистской и запрещена в РФ) представила GraphQL — язык запросов, позволяющий клиенту точно указывать, какие данные ему нужны. Примерно в то же время компания Google разработала gRPC — высокопроизводительный фреймворк для удалённого вызова процедур (RPC), основанный на Protocol Buffers и HTTP/2.

REST (Representational State Transfer)

REST — это архитектурный стиль, а не протокол. Он опирается на шесть ограничений (архитектурных принципов): клиент-серверная архитектура, отсутствие состояния (stateless), кэширование, единообразие интерфейса (uniform interface), слоистая система и код по требованию (опционально). Ключевая идея — каждый ресурс (например, пользователь, заказ, статья) идентифицируется уникальным URL, а операции над ним выполняются с помощью стандартных HTTP-методов: GET (чтение), POST (создание), PUT (полное обновление), PATCH (частичное обновление), DELETE (удаление).

Принципы и особенности

• Ресурсно-ориентированный подход: всё, что можно назвать, является ресурсом.
• Отсутствие состояния: каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для его обработки. Сервер не хранит контекст сессии между запросами.
• Единообразие интерфейса: использование стандартных HTTP-методов, кодов состояния (200 OK, 404 Not Found, 500 Internal Server Error) и MIME-типов.
• Форматы данных: чаще всего JSON, реже XML, YAML, HTML.
• Кэширование: ответы могут быть помечены как кэшируемые, что снижает нагрузку на сервер.

Преимущества и недостатки

• Плюсы: простота, лёгкость освоения, широкая поддержка во всех языках программирования и фреймворках, хорошая масштабируемость за счёт кэширования и stateless-архитектуры.
• Минусы: избыточность данных (over-fetching) — сервер часто возвращает больше данных, чем нужно клиенту; необходимость нескольких запросов для получения связанных данных (under-fetching); отсутствие строгой типизации и контракта на уровне протокола.

Применение

REST широко используется в веб-приложениях, мобильных API, публичных сервисах (например, API социальных сетей, платёжных систем, облачных провайдеров). Он является стандартом де-факто для большинства публичных и внутренних веб-интерфейсов.

gRPC (gRPC Remote Procedure Call)

gRPC — это высокопроизводительный фреймворк для удалённого вызова процедур (RPC), разработанный компанией Google и открытый в 2015 году. В отличие от REST, gRPC не использует HTTP-методы и URL для ресурсов, а определяет сервисы и методы с помощью языка описания интерфейсов (IDL) — Protocol Buffers (protobuf). Клиент вызывает метод на сервере так же, как локальную функцию, а gRPC берёт на себя сериализацию, передачу и десериализацию данных.

Архитектура и протоколы

• Protocol Buffers: бинарный формат сериализации данных, более компактный и быстрый, чем JSON. Схема данных (.proto-файл) является контрактом между клиентом и сервером.
• HTTP/2: gRPC работает поверх HTTP/2, что обеспечивает мультиплексирование (несколько запросов по одному соединению), сжатие заголовков, поддержку потоковой передачи данных в обоих направлениях.
• Типы взаимодействия: унарный (один запрос — один ответ), серверный стриминг (один запрос — поток ответов), клиентский стриминг (поток запросов — один ответ), двунаправленный стриминг (потоки запросов и ответов одновременно).

Преимущества и недостатки

• Плюсы: высокая производительность (бинарный протокол, HTTP/2), строгая типизация и автоматическая генерация кода на многих языках, поддержка потоковой передачи данных, встроенная аутентификация и балансировка нагрузки.
• Минусы: сложность отладки (бинарный трафик нечитаем без инструментов), ограниченная поддержка в браузерах (требуется gRPC-web или прокси), более крутая кривая обучения по сравнению с REST, меньшая экосистема публичных инструментов.

Применение

gRPC оптимален для микросервисной архитектуры, где требуется высокая скорость и эффективность обмена данными между внутренними сервисами, а также для систем реального времени (стриминг видео, IoT, финансовые транзакции). Его часто используют в облачных платформах (Google Cloud, Netflix, Uber).

GraphQL

GraphQL — это язык запросов для API и среда выполнения для выполнения этих запросов с существующими данными. Он был разработан компанией Facebook (организация признана экстремистской и запрещена в РФ) в 2012 году и открыт в 2015 году. В отличие от REST, где клиент получает фиксированную структуру данных с конкретного URL, GraphQL позволяет клиенту точно указать, какие поля и какие связанные объекты он хочет получить, и сервер возвращает ровно это.

Принципы работы

• Схема (Schema): GraphQL API описывается единой схемой, которая определяет типы данных, их поля и связи между ними. Схема является контрактом.
• Запросы (Query): клиент отправляет один запрос к единой конечной точке (endpoint), в котором перечисляет необходимые поля. Например, query { user(id: 1) { name, email, posts { title } } } вернёт только имя, email и заголовки постов пользователя.
• Мутации (Mutation): операции изменения данных (создание, обновление, удаление).
• Подписки (Subscription): механизм для получения данных в реальном времени через WebSocket.

Преимущества и недостатки

• Плюсы: точное получение данных без избыточности (over-fetching) и без недостаточности (under-fetching), один запрос вместо нескольких, строгая типизация и документирование через схему, удобство для быстро меняющихся требований клиента.
• Минусы: сложность реализации на сервере (необходимость разрешения графовых запросов), потенциальные проблемы с производительностью (клиент может запросить слишком глубокие вложенные данные), сложность кэширования (URL не является уникальным идентификатором ресурса), меньшая зрелость инструментов по сравнению с REST.

Применение

GraphQL активно используется в сложных клиентских приложениях (веб и мобильные), где требуется гибкость в получении данных, например, в социальных сетях, интернет-магазинах, панелях управления. Его применяют такие компании, как GitHub, Shopify, The New York Times.

Сравнение REST, gRPC и GraphQL

Выбор подходящего API

Выбор между REST, gRPC и GraphQL зависит от конкретных задач:

• REST — универсальный выбор для публичных API, простых веб-сервисов, когда важна простота и широкая совместимость.
• gRPC — предпочтителен для внутренних микросервисов, систем с высокой нагрузкой, потоковой передачи данных, когда производительность критична.
• GraphQL — оптимален для сложных клиентских приложений с разнообразными потребностями в данных, когда требуется гибкость и минимизация сетевых запросов.

На практике часто используются гибридные подходы: например, публичный REST API для внешних клиентов, внутренний gRPC для микросервисов и GraphQL для веб-приложения.

Интересные факты

• Термин REST был введён Роем Филдингом, одним из главных разработчиков протокола HTTP/1.1.
• gRPC изначально назывался просто «GRPC» (Generic RPC), но позже был переименован в gRPC (gRPC Remote Procedure Calls).
• GraphQL часто называют «языком запросов для API», но технически это спецификация, а не язык программирования.
• Все три подхода активно развиваются: REST остаётся стандартом, gRPC набирает популярность в микросервисах, а GraphQL — в клиентских приложениях.

Источники

• Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures (докторская диссертация). University of California, Irvine.
• Документация gRPC. grpc.io
• Спецификация GraphQL. graphql.org
• Документация REST API. restfulapi.net
• Статья «Comparing API Architectural Styles: REST, gRPC, GraphQL» (2023).