gRPC vs REST: сравнение по пунктам

Ранее мы уже делали посты про REST и SOAP, а также сравнивали их по пунктам. В предыдущем посте мы рассмотрели основные аспекты gRPC. Теперь сравним его с REST, чтобы понять, когда что использовать для проектирования API.

Protobuf вместо JSON / XML

REST: Обычно используются форматы сообщений JSON / XML / YAML. Такой формат удобен и понятен для человека, но обратная сторона этого – скорость передачи сообщений.
gRPC: Использует двоичный формат обмена сообщениями Protobuf. За счёт сжатия и бинарной сериализации это позволяет увеличить скорость передачи сообщений в разы. Обратная сторона – формат Protobuf нечеловекочитаем.

HTTP/2 вместо HTTP 1/1

REST: Обычно используются HTTP 1/1, который предполагает взаимодействие по типу запрос-ответ. Это означает, что когда микросервис получает несколько запросов от более чем одного клиента, он должен обслуживать их по одному, что замедляет работу всей системы.
gRPC: Использует HTTP/2 и позволяет группировать запросы в пакеты и устанавливать двунаправленное соединение. Теперь, когда микросервис получает несколько запросов от более чем одного клиента, он может обслуживать их одновременно и отдавать ответы в режиме реального времени.

gRPC строго определяет контракт

REST: Не даёт чёткого определения того, как должны быть описаны контракты. Да, можно использовать OpenAPI и Swagger для генерации кода, но на практике такое встречается нечасто. Обычно наоборот: из кода генерируют Swagger и вставляют в Confluence.
gRPC: Есть строгое определение того, как должны выглядеть запросы и ответы. Контракт определяется в файле .proto, который описывает типы сообщений и сервисы, которые предоставляются. Затем proto-файлы клиент может преобразовать в заглушки с помощью готовых плагинов кодогенерации от Google для разных языков программирования.

gRPC API дольше реализовывать

REST: Это мейнстрим и огромное коммьюнити, лёгкость и простота. Существует множество фреймворков и библиотек, которые упрощают разработку и тестирование REST API.
gRPC: Требует гораздо более серьёзного погружения и менее распространён. Для создания gRPC API необходимо использовать специальный формат данных Protobuf и определять контракты в файлах .proto. Также нужно учитывать особенности HTTP/2 и потоковой передачи данных.

Что выбрать

gRPC не является полной заменой REST во всех кейсах. API на gRPC может оказаться лучше REST в следующих случаях:

Общение микросервисов между собой: связь с низкой задержкой и высокой пропускной способностью gRPC делает его особенно полезным для подключения архитектур, состоящих из легких микросервисов, где эффективность передачи сообщений имеет первостепенное значение.
Системы где используется несколько языков программирования благодаря поддержке генерации собственного кода для широкого спектра языков разработки.
Потоковая передача в реальном времени: когда требуется связь в реальном времени, способность gRPC управлять двунаправленной потоковой передачей позволяет системе отправлять и получать сообщения в режиме реального времени, не дожидаясь ответа отдельного клиента.
Сети с низким энергопотреблением и низкой пропускной способностью, например, IoT: использование gRPC сериализованных сообщений Protobuf обеспечивает легкий обмен сообщениями, большую эффективность и скорость по сравнению с JSON.

Сравнительная таблица gRPC и REST

Критерий	gRPC	REST
Чем является	Фреймворк	Архитектурный стиль
Парадигма доступа к данным	Удалённый вызов процедур	Обращение к ресурсам
Вендор	Google	Нет
Год создания	2015	2000
Транспортный протокол	HTTP/2	HTTP/1.1
Формат сообщений	Protobuf (бинарный и нечеловекоочитаемый)	Человекоочитаемый текстовый (JSON, XML и другие)
Производительность	Высокая, данные изначально сериализованы	Средняя, данные требуют дополнительной сериализации
Поддержка двунаправленного соединения	Есть благодаря HTTP/2	Нет
Скорость обмена	Выше в 7-10 раз, за счёт Protobuf и двунаправленного потокового соединения	Ниже, обмен однонаправленный (запрос-ответ)
Сложность реализации	Сложнее, необходимо использовать специальный формат данных Protobuf и определять контракты в файлах `.proto`	Проще, много готовых решений и фреймворков
Кодогенерация	Встроена, автоматическая генерация кода для загрузки клиентских приложений proto-контракта	Требуется стороннее решение, не всегда применимо
Контракт	Строго требует определения контракта	Контракт не является строго определяемым
Гибкость	Менее гибкий, так как требует строгого определения	Более гибкий, свободное определение ресурсов и операций над ними
Масштабирование	Высокое, благодаря эффективному использованию сетевых ресурсов и двунаправленным соединениям	Низкое, из-за ограничений по количеству соединений и сериализации данных
Тестируемость	Можно использовать стандартные или библиотеки для создания моков и автотестов	Стандартные инструменты или браузер для отправки получений текстового формата API
Трассировка запросов	Не поддерживается из коробки, но позволяет интеграцию с различными инструментами и платформами	Может использовать стандартные заголовки HTTP для передачи информации о трассировке
Балансировка нагрузки	Требует специальной конфигурации и инструментов	Обычно реализуется на стороне сервера. Может использовать стандартные решения
Лучше всего подходит для	Высокопроизводительных микросервисных архитектур или архитектур с большим объемом данных	Простых источников данных с чётко определенными ресурсами

Подборка материалов

Статьи

gRPC vs REST, что выбрать для нового сервера? — Хабр. Есть также видео.
Сравнение от Amazon.

Видео

gRPC vs REST, что выбрать для нового сервера? — видео о статье 1.
gRPC vs REST. Плюсы и минусы на примере реального проекта.

Protobuf вместо JSON / XML​

HTTP/2 вместо HTTP 1/1​

gRPC строго определяет контракт​

gRPC API дольше реализовывать​

Что выбрать​

Сравнительная таблица gRPC и REST​

Подборка материалов​

Статьи​

Видео​