Как ответить
Главное отличие REST от gRPC — в формате передачи данных и модели взаимодействия. REST использует HTTP/1.1 и текстовые форматы (JSON/XML), а gRPC — HTTP/2 и бинарный протокол Protobuf. Это даёт gRPC преимущество в производительности, но усложняет отладку и совместимость.
Начну с протокола. REST работает поверх HTTP/1.1: каждый запрос — отдельное TCP-соединение, заголовки не сжимаются, тело — читаемый JSON. gRPC использует HTTP/2: мультиплексирование потоков на одном соединении, бинарные заголовки в формате HPACK, тело — сериализованные Protobuf-сообщения. Это снижает накладные расходы на 30–50% на типичных микросервисных запросах (по тестам Google).
Второе отличие — контракты. В REST контракт — это OpenAPI-спецификация (Swagger), которая описывает эндпоинты, методы и схемы. В gRPC контракт задаётся через .proto-файл: строгая типизация, обязательные и опциональные поля, версионирование через package. Protobuf генерирует клиентские и серверные стабы для всех языков автоматически. Это исключает рассинхронизацию типов, но требует генерации кода на этапе сборки.
Третье — модели взаимодействия. REST поддерживает только request-response. gRPC даёт четыре модели: unary (один запрос — один ответ), server-streaming (один запрос — поток ответов), client-streaming (поток запросов — один ответ) и bidirectional streaming (два потока). На практике server-streaming удобен для логов или уведомлений, а bidirectional — для чатов или real-time аналитики. REST для такого пришлось бы городить polling или WebSocket.
Четвёртое — производительность в бенчмарках. В тесте от Google (2020) gRPC обработал 1000 запросов за 2.3 секунды против 6.8 секунд у REST на том же железе. Размер сообщения — 120 байт у Protobuf против 480 байт у JSON для одинаковых данных. Но это справедливо для внутренних сервисов с низкой латентностью. Для внешних API, где важна читаемость и кэширование на CDN, REST остаётся стандартом.
Пятое — инструменты. REST легко тестировать через curl, Postman, браузер. gRPC требует специальных утилит: grpcurl, Evans, или gRPC UI. Логи бинарные — без декодирования не прочитать. Это проблема при отладке в production: нужно либо включать reflection-сервер, либо парсить логи отдельным инструментом.
Итог: gRPC выбирают для high-load микросервисов, где важна скорость и строгая типизация. REST — для публичных API, где нужна простота интеграции и человекочитаемость.