REST vs GraphQL vs gRPC — когда выбирать каждый?

Question

IT Interview Practice · Accepted Answer

Это три разных парадигмы API, каждая оптимизирована под разные ограничения. Универсального победителя нет — правильный выбор зависит от **потребителя, формы данных и сети**.

## Три вкратце

```text
           REST                 GraphQL              gRPC
Style      resources + HTTP     single query graph   RPC (call methods)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binary)
Fetching   fixed endpoints      client picks fields  fixed methods
Schema     optional (OpenAPI)   strong, typed        strong, .proto
Browser    native, cacheable    needs client lib     limited (needs proxy)
```

## REST

Ресурсо-ориентированный поверх обычного HTTP. **Выбирайте его** для публичных API, CRUD-сервисов и всего, что выигрывает от HTTP-кэширования, повсеместности и простоты. Его слабости — **over-fetching** (вы получаете весь `/users/42`, даже если нужно одно поле) и **under-fetching** (проблема `N+1`: получить пользователя, затем в цикле получать каждый заказ).

```http
GET /users/42            → the whole user
GET /users/42/orders     → a second round trip
```

## GraphQL

Единый endpoint, где **клиент указывает точно, что ему нужно**, в одном запросе, решая over/under-fetching. **Выбирайте его** для богатых фронтендов (особенно мобильных, где round trips дороги) и когда многим клиентам нужны разные формы одних и тех же данных.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
Компромиссы: HTTP-кэширование сложнее (всё — это `POST` на `/graphql`), а наивный resolver может скрывать дорогие `N+1` запросы к базе.

## gRPC

Contract-first RPC с использованием **Protobuf** поверх **HTTP/2**. Бинарный и мультиплексированный, поэтому быстрый и компактный с поддержкой стриминга. **Выбирайте его** для **внутреннего service-to-service** взаимодействия в бэкенде микросервисов, где важны производительность и строгая типизация. Слабость: плохая поддержка браузера (нужен прокси вроде grpc-web) и нечитаемость человеком.

## Как выбирать

```text
Public API, CRUD, caching, wide reach   → REST
Complex/varied frontend data needs      → GraphQL
High-performance internal microservices → gRPC
(Real systems mix them: REST/GraphQL at the edge, gRPC between services.)
```

## Почему это важно

На уровне senior интервьюеров меньше волнуют определения и больше — можете ли вы **обосновать выбор против ограничений** — этот вопрос на самом деле про «умеете ли вы подобрать технологию под задачу, а не гнаться за хайпом?». Сильнейшие ответы опираются на боль, которую решает каждая: GraphQL существует, чтобы убить over/under-fetching для требовательных фронтендов, gRPC существует, чтобы сделать внутренние вызовы сервисов быстрыми и строго типизированными, а REST остаётся выбором по умолчанию, потому что HTTP-кэширование, инструментарий и всеобщая привычность — огромные практические преимущества для публичных и CRUD-подобных API. Важно, что senior-инженер отмечает, что это **не «или-или»** — распространённая архитектура это REST или GraphQL на публичном краю с gRPC между бэкенд-микросервисами — и называет конкретные компромиссы (риски кэширования и `N+1` у GraphQL, слабая браузерная история у gRPC). Именно это рассуждение о соответствии и стоимости, а не способность перечислить фичи, и есть сигнал.

Три вкратце

REST

GraphQL

gRPC

Как выбирать

Почему это важно

Похожие вопросы