🆚 gRPC vs REST: сравнение по пунктам
Ранее мы уже делали посты про REST и SOAP, а также сравнивали их по пунктам. А
в предыдущем посте мы рассмотрели основные аспекты gRPC. Теперь сравним его с REST, чтобы понять, когда что использовать для проектирования API.
Protobuf вместо JSON / XML
🔹 Обычно в REST используются форматы сообщений JSON / XML / YAML. Такой формат удобен и понятен для человека, но обратная сторона этого – скорость передачи сообщений
🔸 В gRPC использует двоичный формат обмена сообщениями Protobuf . За счёт сжатия и бинарной сериализации это позволяет увеличить скорость передачи сообщений в разы. Обратная сторона – формат Protobuf нечеловекочитаем
HTTP/2 вместо HTTP 1/1
🔹 Обычно в REST API используются HTTP 1/1, который предполагает взаимодействие по типу запрос-ответ. Это означает, что когда микросервис получает несколько запросов от более чем одного клиента, он должен обслуживать их по одному, что замедляет работу всей системы.
🔸 gRPC использует HTTP/2 и позволяет группировать запросы в пакеты и, самое главное, устанавливать двунаправленное соединение. Теперь, когда микросервис получает несколько запросов от более чем одного клиента, он может обслуживать их одновременно и отдавать ответы в режиме реального времени. Клиенту не нужно отправлять несколько запросов последовательно, открывая для каждого запроса новое TCP-соединение (см. модель OSI)
gRPC строго определяет контракт
🔹 В REST не даёт чёткого определения того, как должны быть описаны контракты. Да, можно использовать OpenAPI и Swagger для генерации кода, но на практике такое встречается нечасто, в том числе в силу объективных причин. Обычно наоборот: из кода генерируют сваггер и вставляют в Confluence. У кого есть опыт на этот счёт, пишите в комменты!
🔸 В gRPC есть строгое определение того, как должны выглядеть запросы и ответы. Контракт определяется в файле .proto, который описывает типы сообщений и сервисы, которые предоставляются. Затем proto-файлы клиент может преобразовать в заглушки с помощью готовых плагинов кодогенерации от Google для разных языков программирования
gRPC API дольше реализовывать
🔹 REST – это мейнстрим и огромное коммьюнити, лёгкость и простота. Существует множество фреймворков и библиотек, которые упрощают разработку и тестирование REST API.
🔸 gRPC требует гораздо более серьёзного погружения и менее распространён. Для создания gRPC API необходимо использовать специальный формат данных Protobuf и определять контракты в файлах .proto. Также нужно учитывать особенности HTTP/2 и потоковой передачи данных.
Итак, что выбрать
Таким образом, gRPC не является полной заменой REST во всех кейсах. API на gRPC может оказаться лучше REST в следующих случаях:
1️⃣ Общение микросервисов между собой: связь с низкой задержкой и высокой пропускной способностью gRPC делает его особенно полезным для подключения архитектур, состоящих из легких микросервисов, где эффективность передачи сообщений имеет первостепенное значение.
2️⃣ Системы где используется несколько языков программирования благодаря поддержке генерации собственного кода для широкого спектра языков разработки
3️⃣ Потоковая передача в реальном времени: когда требуется связь в реальном времени, способность gRPC управлять двунаправленной потоковой передачей позволяет системе отправлять и получать сообщения в режиме реального времени, не дожидаясь ответа отдельного клиента.
4️⃣ Сети с низким энергопотреблением и низкой пропускной способностью, например, IoT: использование gRPC сериализованных сообщений Protobuf обеспечивает легкий обмен сообщениями, большую эффективность и скорость по сравнению с JSON.
Статьи
1. gRPC vs REST, что выбрать для нового сервера? — Хабр. Есть также видео
2. Сравнение от Amazon
Видео
1. gRPC vs REST, что выбрать для нового сервера? — видео о статье 1
2. gRPC vs REST. Плюсы и минусы на примере реального проекта
#api #интеграции #сравнение
Ранее мы уже делали посты про REST и SOAP, а также сравнивали их по пунктам. А
в предыдущем посте мы рассмотрели основные аспекты gRPC. Теперь сравним его с REST, чтобы понять, когда что использовать для проектирования API.
Protobuf вместо JSON / XML
🔹 Обычно в REST используются форматы сообщений JSON / XML / YAML. Такой формат удобен и понятен для человека, но обратная сторона этого – скорость передачи сообщений
🔸 В gRPC использует двоичный формат обмена сообщениями Protobuf . За счёт сжатия и бинарной сериализации это позволяет увеличить скорость передачи сообщений в разы. Обратная сторона – формат Protobuf нечеловекочитаем
HTTP/2 вместо HTTP 1/1
🔹 Обычно в REST API используются HTTP 1/1, который предполагает взаимодействие по типу запрос-ответ. Это означает, что когда микросервис получает несколько запросов от более чем одного клиента, он должен обслуживать их по одному, что замедляет работу всей системы.
🔸 gRPC использует HTTP/2 и позволяет группировать запросы в пакеты и, самое главное, устанавливать двунаправленное соединение. Теперь, когда микросервис получает несколько запросов от более чем одного клиента, он может обслуживать их одновременно и отдавать ответы в режиме реального времени. Клиенту не нужно отправлять несколько запросов последовательно, открывая для каждого запроса новое TCP-соединение (см. модель OSI)
gRPC строго определяет контракт
🔹 В REST не даёт чёткого определения того, как должны быть описаны контракты. Да, можно использовать OpenAPI и Swagger для генерации кода, но на практике такое встречается нечасто, в том числе в силу объективных причин. Обычно наоборот: из кода генерируют сваггер и вставляют в Confluence. У кого есть опыт на этот счёт, пишите в комменты!
🔸 В gRPC есть строгое определение того, как должны выглядеть запросы и ответы. Контракт определяется в файле .proto, который описывает типы сообщений и сервисы, которые предоставляются. Затем proto-файлы клиент может преобразовать в заглушки с помощью готовых плагинов кодогенерации от Google для разных языков программирования
gRPC API дольше реализовывать
🔹 REST – это мейнстрим и огромное коммьюнити, лёгкость и простота. Существует множество фреймворков и библиотек, которые упрощают разработку и тестирование REST API.
🔸 gRPC требует гораздо более серьёзного погружения и менее распространён. Для создания gRPC API необходимо использовать специальный формат данных Protobuf и определять контракты в файлах .proto. Также нужно учитывать особенности HTTP/2 и потоковой передачи данных.
Итак, что выбрать
Таким образом, gRPC не является полной заменой REST во всех кейсах. API на gRPC может оказаться лучше REST в следующих случаях:
1️⃣ Общение микросервисов между собой: связь с низкой задержкой и высокой пропускной способностью gRPC делает его особенно полезным для подключения архитектур, состоящих из легких микросервисов, где эффективность передачи сообщений имеет первостепенное значение.
2️⃣ Системы где используется несколько языков программирования благодаря поддержке генерации собственного кода для широкого спектра языков разработки
3️⃣ Потоковая передача в реальном времени: когда требуется связь в реальном времени, способность gRPC управлять двунаправленной потоковой передачей позволяет системе отправлять и получать сообщения в режиме реального времени, не дожидаясь ответа отдельного клиента.
4️⃣ Сети с низким энергопотреблением и низкой пропускной способностью, например, IoT: использование gRPC сериализованных сообщений Protobuf обеспечивает легкий обмен сообщениями, большую эффективность и скорость по сравнению с JSON.
Статьи
1. gRPC vs REST, что выбрать для нового сервера? — Хабр. Есть также видео
2. Сравнение от Amazon
Видео
1. gRPC vs REST, что выбрать для нового сервера? — видео о статье 1
2. gRPC vs REST. Плюсы и минусы на примере реального проекта
#api #интеграции #сравнение