1. Обзор
В этой статье мы сравним REST и gRPC, два архитектурных стиля для веб-API.
2. Что такое ОТДЫХ?
REST (Representational State Transfer) — это архитектурный стиль, предоставляющий рекомендации по разработке веб-API.
Он использует стандартные методы HTTP 1.1, такие как GET , POST , PUT и DELETE , для работы с ресурсами на стороне сервера . Кроме того, REST API предоставляют предварительно определенные URL-адреса , которые клиент должен использовать для подключения к серверу.
3. Что такое gRPC?
gRPC (Remote procedure Call) — технология обмена данными с открытым исходным кодом, разработанная Google с использованием протокола HTTP/2 .
Он использует для обмена данными двоичный формат Protocol Buffers (Protobuf) . Кроме того, этот архитектурный стиль применяет правила, которым должен следовать разработчик при разработке или использовании веб-API.
4. REST против gRPC
4.1. Рекомендации и правила
REST — это набор рекомендаций по разработке веб-API без каких-либо ограничений. С другой стороны, gRPC применяет правила, определяя файл .proto , который должен соблюдаться как клиентом, так и сервером для обмена данными .
4.2. Базовый HTTP-протокол
REST обеспечивает модель связи запрос-ответ, построенную на протоколе HTTP 1.1. Поэтому, когда на сервер поступает несколько запросов, он обязан обрабатывать каждый из них по очереди.
Тем не менее, gRPC следует модели связи с ответом клиента для разработки веб-API, основанных на HTTP/2 . Следовательно, gRPC позволяет осуществлять потоковую связь и одновременно обслуживать несколько запросов . В дополнение к этому, gRPC также поддерживает унарную связь, аналогичную REST .
4.3. Формат обмена данными
REST обычно использует форматы JSON и XML для передачи данных. Однако gRPC полагается на Protobuf для обмена данными по протоколу HTTP/2.
4.4. Сериализация и строгая типизация
REST в большинстве случаев использует JSON или XML, что требует сериализации и преобразования в целевой язык программирования как для клиента, так и для сервера, тем самым увеличивая время отклика и вероятность ошибок при разборе запроса/ответа.
Однако gRPC предоставляет строго типизированные сообщения, автоматически конвертируемые с использованием формата обмена Protobuf в выбранный язык программирования.
4.5. Задержка
REST, использующий HTTP 1.1, требует рукопожатия TCP для каждого запроса. Следовательно, REST API с HTTP 1.1 могут страдать от проблем с задержкой.
С другой стороны, gRPC использует протокол HTTP/2, который использует мультиплексированные потоки. Таким образом, несколько клиентов могут отправлять несколько запросов одновременно, не устанавливая для каждого нового TCP-соединения. Также сервер может отправлять push-уведомления клиентам через установленное соединение.
4.6. Поддержка браузера
REST API на HTTP 1.1 имеют универсальную поддержку браузера.
Однако gRPC имеет ограниченную поддержку браузеров, поскольку многие браузеры (обычно более старые версии) не поддерживают HTTP/2. Таким образом, может потребоваться gRPC-web и прокси-уровень для выполнения преобразований между HTTP 1.1 и HTTP/2. Поэтому на данный момент gRPC в основном используется для внутренних сервисов.
4.7. Особенности генерации кода
REST не предоставляет встроенных функций генерации кода. Однако мы можем использовать сторонние инструменты, такие как Swagger или Postman, для создания кода для запросов API.
С другой стороны, gRPC, использующий компилятор protoc , имеет встроенные функции генерации кода , совместимые с несколькими языками программирования.
5. Вывод
В этой статье мы сравнили два архитектурных стиля для API, REST и gRPC.
Мы пришли к выводу, что REST удобен для интеграции микросервисов и сторонних приложений с основными системами .
Однако gRPC может найти свое применение в различных системах, таких как системы IoT, требующие облегченной передачи сообщений, мобильные приложения без поддержки браузера и приложения, которым требуются мультиплексированные потоки .