REST, GraphQL или gRPC: какой API выбрать

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

Разберём, чем они отличаются и как выбрать под свою задачу.

Чем REST, GraphQL и gRPC отличаются по сути?

REST, GraphQL и gRPC отличаются тем, кто определяет форму ответа и как передаются данные. В REST сервер описывает ресурсы, и клиент получает их целиком по адресу. В GraphQL клиент сам описывает в запросе, какие поля ему нужны. В gRPC клиент вызывает методы сервиса по строго описанному контракту в компактном бинарном формате.

Критерий	REST	GraphQL	gRPC
Кто задаёт форму ответа	Сервер	Клиент	Контракт в .proto-файле
Формат	JSON поверх HTTP	JSON поверх HTTP, один эндпоинт	Protocol Buffers поверх HTTP/2
Кеширование	Стандартное HTTP-кеширование	Сложнее: нужен кеш на уровне клиента или запросов	Своими средствами
Работа из браузера	Нативно	Нативно	Через прокси gRPC-Web
Строгость контракта	OpenAPI по желанию	Схема обязательна	.proto обязателен
Порог входа	Низкий	Средний	Средний и выше
Типичное применение	Публичные и партнёрские API, веб и мобильные клиенты	Сложные интерфейсы с разными клиентами	Связь между внутренними сервисами

Когда REST — лучший выбор?

REST — лучший выбор, когда API нужен веб-фронтенду, мобильному приложению или партнёрам, а модель данных не требует гибких выборок на каждом экране. Это самый распространённый и понятный формат: его знает каждый разработчик, его поддерживает любой инструмент, а ответы кешируются стандартными средствами HTTP и CDN.

REST особенно удобен, когда:

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

Правила, которые делают REST API удобным, мы разбирали в статье как спроектировать REST API.

Когда нужен GraphQL?

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

query OrderScreen($id: ID!) {
  order(id: $id) {
    number
    status
    customer { name phone }
    items { title quantity price }
  }
}

Цена гибкости — сложность на сервере. Без ограничений один запрос может потянуть огромный граф данных, поэтому нужны лимиты глубины и сложности запросов, защита от N+1 через пакетную загрузку и продуманная авторизация на уровне полей. Кешировать ответы по адресу, как в REST, не получится.

Фото: Unsplash

Когда стоит выбрать gRPC?

gRPC стоит выбрать для связи между внутренними сервисами, где важны скорость, строгий контракт и потоковая передача данных. Бинарный формат Protocol Buffers компактнее JSON, HTTP/2 позволяет держать много вызовов в одном соединении, а код клиента и сервера генерируется из одного описания.

syntax = "proto3";

service Payments {
  rpc Charge (ChargeRequest) returns (ChargeResult);
}

message ChargeRequest {
  string order_id = 1;
  int64 amount = 2;      // в минимальных единицах валюты
  string currency = 3;
}

Ограничения gRPC

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

Поэтому gRPC обычно живёт внутри системы, а наружу смотрит REST или GraphQL. Если сервисов в системе пока нет, вопрос выбора протокола между ними тоже можно отложить — об этом в статье монолит или микросервисы.

Можно ли совмещать несколько подходов?

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

Типичные комбинации:

1. REST наружу, gRPC внутри. Публичный API для клиентов и партнёров, быстрые вызовы между сервисами.
2. GraphQL для фронтенда, REST для партнёров. Гибкие выборки для своих интерфейсов и простой стабильный API для внешних систем.
3. REST плюс вебхуки. Партнёр вызывает API, а система уведомляет его о событиях — оплате, смене статуса.

Главное — не выбирать протокол «на вырост». Добавить GraphQL поверх работающего REST или перевести внутренние вызовы на gRPC можно тогда, когда появится конкретная причина.

Коротко

• REST — выбор по умолчанию для веба, мобильных приложений и партнёров: просто и кешируется.
• GraphQL — когда много клиентов запрашивают разные срезы одной сложной модели; требует лимитов и защиты.
• gRPC — для быстрой связи между внутренними сервисами со строгим контрактом.
• Подходы можно совмещать: REST наружу, gRPC внутри, GraphQL для своих интерфейсов.
• Выбирайте протокол под текущую задачу, а не «на вырост».