gRPC vs REST: в чём разница и что выбрать для API

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

REST остаётся самым массовым стилем API: по данным Postman 2025 State of the API Report, его используют 93% команд — заметно больше, чем webhooks (50%), WebSocket (35%) и GraphQL (33%). При этом внутри микросервисных систем всё чаще звучит другое слово — gRPC: открытый RPC-фреймворк, созданный в Google и развивающийся как проект фонда CNCF, который работает поверх HTTP/2 и сериализует данные в Protocol Buffers. Microsoft Learn прямо рекомендует его для межсервисного взаимодействия и сценариев с потоковой передачей. Отсюда и вечный вопрос архитекторов: gRPC vs REST — что выбрать для нового API?

Цена ошибки здесь выше, чем кажется. Протокол API — это договор между сервером и всеми его клиентами: веб-интерфейсом, мобильным приложением, партнёрскими интеграциями, соседними сервисами. Сменить его через год — значит переписывать клиентов, пересогласовывать интеграции и держать два контракта одновременно. Поэтому, когда мы проектируем REST и gRPC API в рамках разработки API на заказ, выбор протокола обсуждаем на этапе архитектуры, а не «по привычке команды».

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

Что такое REST API

REST (Representational State Transfer) — это архитектурный стиль построения распределённых систем, который Рой Филдинг описал в своей диссертации в 2000 году. REST — не протокол и не стандарт, а набор ограничений: клиент-серверное разделение, отсутствие состояния на сервере между запросами (stateless), кэшируемость ответов, единообразный интерфейс и многоуровневость системы.

На практике REST API строится вокруг ресурсов. Каждый ресурс — заказ, пользователь, товар — имеет свой адрес (URI), а действия над ним выражаются стандартными HTTP-методами:

• GET — получить ресурс или список ресурсов;
• POST — создать новый ресурс;
• PUT / PATCH — заменить или частично изменить ресурс;
• DELETE — удалить ресурс.

Результат операции передаётся кодом состояния HTTP (200, 201, 404, 409, 500), а данные — чаще всего в текстовом формате JSON. Вот как выглядит типичный запрос и ответ:

GET /api/v1/orders/42 HTTP/1.1
Host: api.example.ru
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60

{
  "id": 42,
  "status": "shipped",
  "total": 15900,
  "items": [{"sku": "A-17", "qty": 2}]
}

Главная сила REST — в универсальности. Такой запрос можно отправить из браузера, curl, Postman, 1С или любого языка программирования без специальных библиотек, прочитать глазами и закэшировать на CDN. Именно поэтому REST стал стандартом де-факто для публичных API и интеграций. Подробнее о принципах проектирования мы писали в статье «Клиент-серверная архитектура: как разрабатывать web API».

Что такое gRPC

gRPC — это open-source фреймворк удалённого вызова процедур (RPC), который Google открыл в 2015 году на базе своей внутренней системы Stubby. Идея RPC проста: клиент вызывает метод на удалённом сервере так, будто это обычная локальная функция, — вся сетевая механика скрыта в сгенерированном коде. Как описывает официальная документация gRPC, фреймворк опирается на два столпа: транспорт HTTP/2 и формат сериализации Protocol Buffers.

Если REST мыслит ресурсами («дай заказ 42»), то gRPC мыслит действиями («вызови метод GetOrder с аргументом 42»). Контракт описывается в файле .proto — это единый источник истины для сервера и всех клиентов:

syntax = "proto3";

package shop.v1;

service OrderService {
  rpc GetOrder (GetOrderRequest) returns (Order);
  rpc TrackOrder (GetOrderRequest) returns (stream OrderStatus);
}

message GetOrderRequest {
  int64 id = 1;
}

message Order {
  int64 id = 1;
  string status = 2;
  int64 total = 3;
}

message OrderStatus {
  string status = 1;
  int64 updated_at = 2;
}

Как работает вызов: от .proto до сгенерированного клиента

Процесс разработки на gRPC выглядит так: команда описывает сервис и сообщения в .proto-файле, затем компилятор protoc с плагинами генерирует из него код — серверные заглушки и клиентские библиотеки. Официально поддерживается больше десяти языков: Go, Java, Kotlin, C#, C++, Python, Node.js, Ruby, PHP, Dart, Swift и другие. Разработчику остаётся реализовать бизнес-логику методов на сервере, а на клиенте — просто вызвать client.GetOrder(request).

Под капотом клиент сериализует аргумент в компактный бинарный protobuf, отправляет его HTTP/2-запросом на путь вида /shop.v1.OrderService/GetOrder, а сервер декодирует сообщение, выполняет метод и возвращает ответ в том же формате. Ни один разработчик при этом не пишет вручную URL, парсинг JSON или обработку кодов состояния.

Четыре типа вызовов gRPC

Главное функциональное отличие gRPC от классического REST — встроенная поддержка потоков. Фреймворк предлагает четыре типа вызовов:

• Unary — один запрос, один ответ. Аналог обычного REST-вызова, самый частый вариант.
• Server streaming — один запрос, поток ответов. Например, подписка на статус заказа или котировки.
• Client streaming — поток запросов, один итоговый ответ. Например, загрузка телеметрии с датчика пачками.
• Bidirectional streaming — оба потока независимы и идут одновременно. Подходит для чатов, совместного редактирования, голосовых ассистентов.

В чём разница между gRPC и REST — сравнительная таблица

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

Критерий	REST	gRPC
Модель API	Ресурсы и HTTP-методы (GET /orders/42)	Методы сервиса (OrderService.GetOrder)
Транспорт	Обычно HTTP/1.1, возможен HTTP/2	Только HTTP/2 (экспериментально — HTTP/3)
Формат данных	Текстовый JSON (реже XML)	Бинарный Protocol Buffers
Контракт	Необязателен, опционально OpenAPI	Обязателен, файл .proto
Кодогенерация	Опционально, через сторонние генераторы OpenAPI	Встроена, клиенты и сервер из .proto
Стриминг	Нет нативного; SSE, WebSocket, long polling	Нативно: server, client и bidirectional
Поддержка браузеров	Полная, из коробки	Только через gRPC-Web и прокси
HTTP-кэширование и CDN	Да (Cache-Control, ETag)	Нет стандартного, кэш строится вручную
Читаемость и отладка	Человекочитаемо, curl и браузер	Бинарно, нужны grpcurl, Postman gRPC
Порог входа	Низкий, специалистов много	Выше: protobuf, HTTP/2, инструменты
Типичные сценарии	Публичные API, веб, партнёры, CRUD	Микросервисы, стриминг, высокие нагрузки

Вывод из таблицы: gRPC выигрывает в эффективности, строгости контракта и стриминге, REST — в совместимости, простоте и экосистеме. Это не «хороший и плохой» протоколы, а инструменты под разные границы системы: REST — для границы с внешним миром, gRPC — для обмена внутри.

Протокол и формат данных: HTTP/2 и Protobuf против HTTP/1.1 и JSON

Протокол и формат сериализации — это фундамент, из которого вытекает большая часть различий в скорости, размере трафика и удобстве отладки. Разберём обе составляющие отдельно.

Сериализация: бинарный protobuf против текстового JSON

Protocol Buffers — это бинарный формат сериализации, в котором вместо имён полей передаются их короткие числовые номера, а числа кодируются компактно, переменной длиной. Как отмечает документация Protocol Buffers, формат задуман как более компактный и быстрый в разборе, чем текстовые форматы, и при этом строго типизированный.

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

• Размер. Protobuf-сообщение обычно в несколько раз меньше эквивалентного JSON, что экономит трафик — особенно в мобильных сетях.
• Скорость разбора. Бинарный парсинг по заранее известной схеме требует меньше CPU, чем разбор текста.
• Типизация. В protobuf поле total — всегда int64; в JSON клиент может получить строку, null или число с плавающей точкой, и это приходится проверять вручную.
• Читаемость. Здесь выигрывает JSON: ответ видно в браузере и логах без инструментов, protobuf без схемы — просто набор байтов.

HTTP/2: мультиплексирование, сжатие заголовков, долгоживущие соединения

HTTP/2 — это вторая мажорная версия протокола HTTP, стандартизированная в RFC 9113. Его ключевое преимущество — мультиплексирование: множество запросов и ответов идут параллельно по одному TCP-соединению в виде независимых потоков (streams), не дожидаясь друг друга. В HTTP/1.1 клиенту приходится либо ждать ответа, либо открывать несколько соединений.

Кроме того, HTTP/2 сжимает заголовки (HPACK), что заметно при множестве мелких вызовов с одинаковыми заголовками авторизации, и изначально рассчитан на долгоживущие соединения — именно на этом построен стриминг gRPC.

Важное уточнение: REST тоже может работать поверх HTTP/2, и большинство современных серверов и CDN это поддерживают. Но переход на HTTP/2 сам по себе не даёт REST ни обязательного контракта, ни бинарной сериализации, ни нативных двунаправленных потоков. Для gRPC HTTP/2 — не опция, а обязательная основа.

Какой протокол быстрее — производительность gRPC и REST

Производительность API складывается из двух разных метрик: латентности (сколько миллисекунд занимает один вызов, обычно смотрят p50 и p95) и пропускной способности (сколько запросов в секунду выдерживает сервис на том же железе). gRPC, как правило, выигрывает по обеим — за счёт компактной сериализации, переиспользования соединений и мультиплексирования.

По публичным бенчмаркам разница в пропускной способности между gRPC и REST/JSON достигает 3–10 раз в зависимости от размера сообщений и характера нагрузки. Важно понимать, что это синтетические замеры на специально подобранных сценариях. На малых нагрузках — единицы или десятки запросов в секунду — разница несущественна: время ответа определяют запросы к базе данных и бизнес-логика, а не формат сериализации.

Сам фреймворк тоже требует грамотной настройки: руководство gRPC по производительности советует переиспользовать каналы, а не создавать их на каждый вызов, использовать стриминг для длинных последовательностей сообщений и следить за лимитами одновременных потоков в одном соединении. Без этого часть преимущества теряется.

Когда производительность действительно решает:

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

Если же вы строите CRUD-админку для десятка сотрудников или корпоративный портал с умеренной нагрузкой, выбор gRPC ради скорости почти наверняка не окупится: пользователи не заметят разницы, а команда потратит время на инфраструктуру.

Стриминг и работа в реальном времени

Стриминг — это передача последовательности сообщений в рамках одного вызова, без повторного установления соединения. В gRPC он встроен в сам протокол: достаточно добавить слово stream в описание метода, и сгенерированный код отдаст разработчику поток сообщений вместо одного ответа.

В REST нативного стриминга нет, и для реального времени используют обходные пути:

• Polling — клиент опрашивает сервер раз в N секунд. Просто, но расточительно: большинство ответов пустые.
• Long polling — сервер держит запрос открытым до появления данных. Меньше пустых ответов, но сложнее в масштабировании.
• Server-Sent Events (SSE) — однонаправленный поток событий от сервера к браузеру. Хорош для уведомлений и лент.
• Webhooks — сервер сам вызывает URL клиента при событии. Стандарт для интеграций между компаниями.
• WebSocket — отдельный протокол двунаправленной связи. Гибок, но без схемы сообщений и кодогенерации.

Типичные сценарии, где gRPC-стримы дают реальную выгоду: котировки и биржевые данные, трекинг курьера или транспорта на карте, телеметрия IoT-устройств, чаты и совместная работа, передача больших файлов частями, распределённые вычисления с потоковой обработкой.

У долгоживущих соединений есть и операционная цена. Балансировщики, работающие на уровне L4, «прилипают» к одному бэкенду на всё время соединения, поэтому для gRPC нужна балансировка на уровне L7 (Envoy, NGINX с поддержкой gRPC, service mesh) или клиентская балансировка. Отдельно настраивают таймауты простоя, keepalive-пинги и корректное переподключение клиентов после разрыва.

Контракт, кодогенерация и версионирование API

Контракт API — это формальное описание того, какие методы доступны, какие данные они принимают и возвращают. В gRPC контракт обязателен: без .proto-файла сервис просто не собрать. В REST контракт опционален — его описывают в спецификации OpenAPI (Swagger), но многие команды обходятся документацией в вики или вообще «договорённостями в чате».

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

Эволюция API тоже устроена по-разному:

• gRPC и protobuf. Поля идентифицируются номерами, а не именами. Можно добавлять новые поля — старые клиенты их просто проигнорируют; нельзя менять номер или тип существующего поля и переиспользовать номера удалённых (их помечают как reserved). При соблюдении этих правил обратная совместимость сохраняется без смены версии.
• REST. Добавление необязательного поля в JSON обычно безопасно, а переименование, удаление или смена типа — breaking change. Для несовместимых изменений заводят новую версию: /api/v1/ → /api/v2/ или версию в заголовке, и какое-то время поддерживают обе.

В обоих мирах работает общий принцип из Google Cloud API Design Guide: проектировать API вокруг ресурсов и стабильных сущностей, а версию менять только при реально несовместимых изменениях. Этот гайд, кстати, применим и к gRPC, и к REST одновременно — Google использует его для своих API в обоих форматах.

Поддержка браузеров, мобильных клиентов и партнёров

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

Браузеры. Браузерные API не дают JavaScript-коду полного контроля над HTTP/2-фреймами и трейлерами, которые нужны «чистому» gRPC. Поэтому напрямую из браузера gRPC-сервис не вызвать. Решение — gRPC-Web: клиентская библиотека плюс прокси (обычно Envoy), который переводит запросы браузера в полноценный gRPC. Это работает, но добавляет компонент в инфраструктуру, а поддержка стриминга в gRPC-Web ограничена серверными потоками.

Мобильные приложения. На Android и iOS gRPC работает нативно — есть официальные библиотеки для Kotlin/Java и Swift. Для мобильных клиентов выгода ощутима: меньше трафика, одно долгоживущее соединение вместо множества, строго типизированные модели из общего контракта. Минус — размер клиентской библиотеки и более сложная отладка. Как в целом проектировать серверную часть для приложения, мы разбирали в материале «API для мобильного приложения: зачем нужен бэкенд и как его спроектировать».

Партнёры и внешние интеграции. Для публичного API, маркетплейсов, платёжных систем и интеграций с 1С и CRM REST — стандарт де-факто. Внешний разработчик ожидает увидеть документацию OpenAPI, попробовать запрос через curl и подключиться за день. Требование ставить protoc и генерировать клиентов резко повышает порог входа и отпугивает интеграторов.

Можно ли использовать gRPC и REST вместе

Да, и в зрелых системах это самый распространённый вариант. Паттерн называется «REST на периметре, gRPC внутри»: внешние клиенты — браузер, партнёры, мобильные приложения старых версий — общаются с системой через привычный REST/JSON, а сервисы между собой обмениваются данными по gRPC.

Типичная схема прохождения запроса выглядит так:

1. Клиент отправляет обычный REST-запрос с JSON: GET /api/v1/orders/42.
2. API Gateway принимает запрос, проверяет токен, применяет лимиты и транслирует REST/JSON в gRPC-вызов OrderService.GetOrder.
3. Внутренние gRPC-сервисы обрабатывают вызов, при необходимости обращаясь друг к другу по gRPC — быстро и со строгим контрактом.
4. База данных и хранилища отдают данные сервисам, а шлюз конвертирует protobuf-ответ обратно в JSON для клиента.

Трансляцию не обязательно писать руками. Для этого есть готовые инструменты:

• grpc-gateway — генерирует REST-прокси прямо из .proto-файла по аннотациям HTTP-маршрутов (популярен в Go-экосистеме);
• JSON transcoding в ASP.NET Core — один и тот же сервис отвечает и на gRPC, и на REST/JSON без отдельного прокси;
• фильтр транскодирования gRPC-JSON в Envoy и аналогичные возможности облачных API-шлюзов.

Плюс такого подхода — единый контракт: .proto-файл остаётся источником истины, а REST-представление и документация OpenAPI генерируются из него. Подробнее о роли шлюза как единой точки входа — в статье «Что такое API Gateway и зачем он нужен микросервисам».

Безопасность, отладка и эксплуатация

Безопасность и эксплуатация API — это то, о чём редко говорят в сравнениях, но что определяет реальную стоимость владения. По базовому уровню защиты протоколы равны, а различаются инструменты и привычки команды.

Шифрование и аутентификация. Оба протокола работают поверх TLS. Для межсервисного обмена в gRPC часто включают mTLS — взаимную проверку сертификатов клиентом и сервером, что удобно делать через service mesh (Istio, Linkerd). Токены (JWT, OAuth 2.0) в REST передаются в заголовке Authorization, в gRPC — в metadata вызова, по сути тоже HTTP/2-заголовках. Авторизацию в обоих случаях удобно выносить в интерсепторы или middleware.

Дедлайны и отмена вызовов. У gRPC есть встроенная механика дедлайнов: клиент указывает, сколько готов ждать, и этот лимит передаётся по цепочке сервисов. Если время вышло или пользователь ушёл со страницы, вызов отменяется на всех уровнях, и сервисы не тратят ресурсы на ненужную работу. В REST таймауты настраиваются на каждом звене отдельно, а распространение отмены приходится реализовывать самостоятельно.

Отладка. REST-запрос можно повторить из браузера, curl или Postman, а ответ прочитать в логах как есть. Для gRPC нужны специальные инструменты: grpcurl, Postman с поддержкой gRPC, Kreya или Insomnia, а на сервере — включённый reflection, чтобы клиент мог узнать схему без .proto-файла. Бинарные сообщения в логах без декодирования нечитаемы.

Наблюдаемость. Для обоих протоколов стандартом стал OpenTelemetry: сквозная трассировка, метрики латентности и ошибок, корреляция логов. У gRPC есть собственная система кодов статуса (OK, NOT_FOUND, DEADLINE_EXCEEDED, UNAVAILABLE и др.), которую нужно корректно маппить в дашбордах и алертах — привычные HTTP 4xx/5xx здесь не работают.

Сколько стоит выбор: сроки, команда и порог входа

Стоимость выбора протокола — это сумма затрат на старт, на разработку фич и на эксплуатацию в течение жизни продукта. gRPC и REST распределяют эти затраты по-разному.

gRPC дороже на старте:

• нужно настроить генерацию кода, хранение и версионирование .proto-файлов, CI-проверки совместимости;
• команде требуется время на освоение protobuf, особенностей HTTP/2 и инструментов отладки;
• для веб-клиентов появляется прокси gRPC-Web или шлюз с транскодированием;
• балансировка и мониторинг требуют L7-решений и отдельной настройки.

gRPC дешевле на масштабе:

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

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

Итоговая логика простая: если нагрузка и число сервисов в обозримом будущем останутся умеренными, стартовые затраты gRPC не окупятся. Если система изначально проектируется как набор микросервисов с плотным обменом данными, вложения в gRPC возвращаются уже на горизонте года эксплуатации.

Когда выбрать REST, а когда gRPC

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

Выбирайте REST, если	Выбирайте gRPC, если
API публичное или партнёрское	API внутреннее, между вашими сервисами
Основной клиент — браузер или SPA	Нужен стриминг в одну или обе стороны
Интеграции с 1С, CRM, маркетплейсами, платёжками	Высокие нагрузки и жёсткие требования к латентности
Простой CRUD без сложных сценариев	Полиглот-команда: сервисы на разных языках
Важен HTTP-кэш и раздача через CDN	Мобильные клиенты в нестабильных сетях
Небольшая команда, MVP, сжатые сроки	IoT и телеметрия с большим числом устройств

Если сценарии из обеих колонок встречаются в одном продукте — это нормальная ситуация, и ответом будет гибридная архитектура с шлюзом, описанная выше. Решения о границах сервисов и протоколах удобнее всего принимать на старте, вместе с общей архитектурой: это часть работы при разработке веб-приложений и микросервисных систем. Если вы ещё выбираете между монолитом и микросервисами, начните с материала «Монолит или микросервисы для веб-приложения» — от этого решения зависит, нужен ли вам межсервисный протокол вообще.

Антипаттерны выбора

• gRPC ради моды в монолите. Одно приложение с CRUD-операциями и веб-интерфейсом не получит от gRPC ничего, кроме лишнего прокси и сложной отладки.
• REST-поллинг раз в секунду вместо стрима. Тысяча клиентов, опрашивающих сервер ежесекундно, создают нагрузку, которую один серверный поток gRPC (или хотя бы SSE) снял бы почти полностью.
• «Чистый» gRPC для публичного API без шлюза. Внешние интеграторы не будут ставить protoc ради одной интеграции — они уйдут к конкуренту с понятным REST.
• Смешение протоколов без правил. Когда одни сервисы общаются по REST, другие — по gRPC, а третьи — через очереди без явной логики, растут затраты на поддержку. Границы протоколов стоит зафиксировать в архитектурных решениях.

Отдельно о третьей и четвёртой опции. GraphQL уместен, когда у вас много разных клиентов с разными потребностями в данных и вы хотите дать им гибкие запросы к одному графу — чаще всего это слой для фронтенда поверх внутренних сервисов. WebSocket выбирают для двунаправленного реального времени в браузере, когда gRPC-Web не подходит, — например, для чатов и онлайн-игр. Эти технологии не конкурируют с gRPC и REST напрямую, а закрывают свои ниши.

Чек-лист выбора API для нового проекта

Чек-лист выбора протокола — это набор вопросов, ответы на которые почти однозначно указывают на REST, gRPC или их комбинацию. Пройдите по нему до начала разработки:

1. Кто потребители API? Внешние партнёры и публичные клиенты — REST; только ваши собственные сервисы — gRPC-кандидат.
2. Нужен ли вызов из браузера? Если да и без промежуточного шлюза — REST; с шлюзом возможен gRPC-Web или транскодирование.
3. Какой объём запросов и требования к латентности? Единицы и десятки RPS — разницы нет; тысячи RPS и цепочки вызовов — аргумент за gRPC.
4. Нужен ли стриминг? Постоянные потоки данных в реальном времени — gRPC; редкие уведомления — хватит webhooks или SSE.
5. Есть ли внешние интеграции? 1С, CRM, маркетплейсы, платёжные системы почти всегда ожидают REST.
6. Какие компетенции у команды? Если никто не работал с protobuf и HTTP/2, заложите время на обучение или начните с REST.
7. Нужен ли HTTP-кэш и CDN? Каталоги, справочники и контент, которые выгодно кэшировать на краю сети, — REST.
8. Готов ли план пилота? Переведите на gRPC один нагруженный внутренний сервис, замерьте p95-латентность, CPU и трафик до и после — и только потом масштабируйте решение.

Частые вопросы о gRPC и REST

gRPC быстрее REST — всегда ли?

Нет. gRPC выигрывает за счёт бинарного protobuf и мультиплексирования HTTP/2, и по публичным бенчмаркам разница в пропускной способности достигает 3–10 раз. Но это проявляется на высоких нагрузках, больших сообщениях и длинных цепочках вызовов. На малых нагрузках время ответа определяют база данных и бизнес-логика, и пользователь разницы не заметит.

Можно ли вызывать gRPC из браузера?

Напрямую — нет: браузерные API не дают полного контроля над HTTP/2, который нужен gRPC. Используют gRPC-Web — клиентскую библиотеку и прокси (обычно Envoy), который переводит запросы браузера в gRPC. Альтернатива — шлюз с JSON-транскодированием: браузер работает с обычным REST, а внутри вызывается gRPC-сервис.

Заменит ли gRPC REST?

Нет, это инструменты для разных задач. REST остаётся стандартом для публичных API, браузеров и интеграций — его используют 93% команд по данным Postman. gRPC занимает нишу внутреннего межсервисного обмена, стриминга и высоконагруженных систем. В зрелых архитектурах они сосуществуют: REST на периметре, gRPC внутри.

Можно ли использовать gRPC и REST в одном проекте?

Да, и это частый вариант. Внешние клиенты обращаются к API Gateway по REST/JSON, а шлюз транслирует запросы в gRPC-вызовы внутренних сервисов. Инструменты вроде grpc-gateway или JSON transcoding в ASP.NET Core генерируют REST-представление прямо из .proto-файла, так что контракт остаётся единым.

Что выбрать для мобильного приложения: gRPC или REST?

Для большинства приложений достаточно REST: он проще в отладке и не требует дополнительных библиотек. gRPC оправдан, если приложение активно обменивается данными в реальном времени (трекинг, чаты, котировки), работает в нестабильных сетях или передаёт большие объёмы структурированных данных — там компактный protobuf и одно соединение экономят трафик и батарею.

Чем gRPC отличается от GraphQL?

gRPC — это фреймворк удалённого вызова методов с жёстким контрактом, бинарным форматом и стримингом, рассчитанный прежде всего на обмен между сервисами. GraphQL — язык запросов, в котором клиент сам описывает, какие поля ему нужны, и получает JSON. GraphQL чаще ставят слоем для фронтенда, gRPC — для внутреннего бэкенда; их нередко используют вместе.