В чем разница между gRPC и REST?
gRPC и REST – два способа разработки API. API – это механизм, который позволяет двум программным компонентам взаимодействовать друг с другом, используя набор определений и протоколов. В gRPC один компонент (клиент) вызывает определенные функции в другом программном компоненте (сервере). В REST вместо вызова функций клиент запрашивает или обновляет данные на сервере.
Что такое gRPC?
Что такое RPC?
В RPC взаимодействие между клиентом и сервером происходит так, как если бы клиентский API-запрос был локальной операцией или запрос был внутренним кодом сервера.
В RPC клиент отправляет запрос процессу на сервере, который постоянно прослушивает удаленные вызовы. В запросе содержится вызываемая серверная функция и все передаваемые параметры. RPC API использует в качестве базового механизма обмена данными протокол типа HTTP, TCP или UDP.
Чем gRPC отличается от RPC?
gRPC – это система, реализующая традиционный RPC с несколькими оптимизациями. Например, gRPC использует Protocol Buffers и HTTP 2 для передачи данных.
Она также абстрагирует механизм обмена данными от разработчика. Например, другая широко распространенная реализация RPC API, OpenAPI, требует от разработчиков сопоставления концепций RPC с протоколом HTTP. Но gRPC абстрагирует базовую HTTP-связь. Эти оптимизации делают gRPC быстрее, проще в реализации и удобнее для работы в Интернете по сравнению с другими реализациями RPC.
Что такое REST?
REST – это подход к архитектуре программного обеспечения, определяющий набор правил для обмена данными между программными компонентами. Он основан на HTTP, стандартном протоколе связи в Интернете. Интерфейсы RESTful API управляют связью между клиентом и сервером с помощью HTTP-команд, таких как POST, GET, PUT и DELETE, для операций создания, чтения, обновления и удаления. Ресурс на стороне сервера идентифицируется по адресу в виде URL.
REST работает следующим образом:
- Клиент делает запрос на создание, изменение или удаление ресурса на сервере.
- Запрос содержит адрес ресурса, а также может включать дополнительные параметры.
- Сервер отвечает, возвращая клиенту весь ресурс после завершения операции.
- Ответ содержит данные в формате JSON и коды состояния.
Интерфейсы API, созданные с использованием рекомендаций REST, называются RESTful API или REST API.
Почему организации используют gRPC и REST?
gRPC и REST – это два разных подхода к разработке API.
Работа с API аналогична заказу блюд в ресторане через меню. В любом ресторане клиент (заказчик) может заказать еду из меню (API), которое имеет фиксированный набор блюд. Эта информация передается на кухню (сервер), которая готовит запрошенное блюдо и выдает его клиенту. Клиенту нужно знать, не как кухня выполняет заказ, а только конечный результат. Стандартизация форматов меню означает, что клиенты и кухни знают, как их использовать.
Без API не было бы общего соглашения о том, как взаимодействуют различные приложения или программные сервисы. Программисты двух разных приложений должны были бы каждый раз общаться друг с другом, чтобы определить способ обмена данными.
Существуют различные типы архитектур API, такие как gRPC и REST, поскольку те или иные могут лучше подходить для различных примеров использования в организации. Разработчик API должен выбрать предпочтительную клиент-серверную архитектуру, исходя из системных требований.
В чем сходство gRPC и REST?
REST и gRPC имеют некоторые общие черты архитектурных подходов к API.
Механизм обмена данными
Обе системы позволяют двум программным компонентам, клиенту и серверу, взаимодействовать и обмениваться данными на основе общего набора правил. Эти правила применяются независимо от внутренней работы каждого программного компонента.
Связь на основе HTTP
Обе системы передают данные через механизм запроса-ответа HTTP, который является предпочтительным эффективным протоколом связи в Интернете. Однако в gRPC это скрыто от разработчика, а в REST это более очевидно.
Гибкость реализации
Как REST, так и gRPC можно реализовать на широком спектре языков программирования. Благодаря этому они хорошо переносятся из одной среды программирования в другую, что обеспечивает оптимальную совместимость с почти универсальной поддержкой.
Пригодность для масштабируемых распределенных систем
И gRPC, и REST используют следующее:
- Асинхронную связь, благодаря которой клиент и сервер могут взаимодействовать, не прерывая операции.
- Архитектуру без фиксации состояния, поэтому серверу не нужно запоминать состояние клиента.
Это означает, что разработчики могут использовать gRPC и REST для создания отказоустойчивых систем с большим количеством одновременных запросов. Можно создавать масштабируемые распределенные системы с несколькими клиентами.
Принципы архитектуры gRPC и REST
Хотя REST и gRPC имеют схожие функции, базовые модели значительно отличаются по своей архитектуре.
Коммуникационная модель
При использовании REST API клиент отправляет на сервер один запрос REST API, а сервер на это отправляет один ответ. Клиент должен дождаться ответа от сервера, прежде чем продолжить работу. Этот механизм представляет собой модель «запрос-ответ» и является одиночной передачей данных (один-к-одному).
При использовании же gRPC клиент может отправить один или несколько API-запросов на сервер, которые могут привести к одному либо нескольким ответам от сервера. Передача данных может быть односторонней (один-к-одному), потоковой (один-ко-многим), потоковой от клиента (многие-к-одному) или двунаправленной (многие-ко-многим). Этот механизм представляет собой коммуникационную модель «ответ для передачи на сторону клиента» и возможен благодаря тому, что gRPC работает на основе HTTP 2.
Вызов операций на сервере
В gRPC API вызов операций на сервере осуществляется сервисами, также известными как функции или процедуры. Клиент gRPC вызывает эти функции так же, как и вы внутри приложения. Это называется сервис-ориентированной архитектурой. Вот пример.
createNewOrder(customer_id, item_id, item_quantity) -> order_id.
В REST существует ограниченный набор HTTP-команд, которые клиент может использовать на ресурсах сервера, определенных URL-адресом. Клиент сам вызывает ресурс. Это называется субъект-ориентированной архитектурой. Субъект-ориентированная архитектура хорошо сочетается с методами объект-ориентированного программирования. Вот пример.
POST /orders <headers> (customer_id, item_id, item_quantity) -> order_id.
Хотя gRPC API можно разрабатывать на основе субъект-ориентированного подхода, это не является ограничением самой системы.
Формат обмена данными
При использовании REST API структуры данных, передаваемые между программными компонентами, обычно выражаются в формате обмена данными JSON. Можно передавать другие форматы данных, такие как XML и HTML. JSON легко читается и является гибким, хотя его необходимо сериализовать и переводить на язык программирования.
В отличие от этого, gRPC по умолчанию использует формат Protocol Buffers (Protobuf), хотя в нем также имеется встроенная поддержка JSON. Сервер определяет структуру данных, используя язык описания интерфейса Protocol Buffer (IDL) в файле протоспецификации. Затем gRPC сериализует структуру в двоичный формат и десериализует ее на любой заданный язык программирования. Этот механизм работает быстрее, чем использование JSON, который не сжимается во время передачи. Формат Protocol Buffers не читабельный для человека, в отличие от JSON, используемого REST API.
Другие ключевые отличия gRPC и REST
Другие ключевые отличия gRPC и REST
Помимо архитектурного стиля, gRPC и REST имеют и другие присущие отличия.
Взаимозависимость «клиент-сервер»
REST имеет слабую взаимосвязь, то есть клиент и сервер не должны ничего знать о реализации друг друга. Такая взаимозависимость облегчает доработку API со временем, поскольку изменение определений сервера не обязательно требует изменения кода на стороне клиента.
gRPC имеет сильную взаимосвязь, то есть клиент и сервер должны иметь доступ к одному и тому же файлу PROTO. Любые обновления файла требуют обновлений как на стороне сервера, так и на стороне клиента.
Генерация кода
gRPC имеет встроенный набор функций генерации внутреннего кода на сторонах клиента и сервера. Они доступны на нескольких языках благодаря протоколу-компилятору Protocol Buffers. После определения структуры в файле PROTO система gRPC генерирует код на сторонах клиента и сервера. Генерация кода делает разработку API менее затратной по времени.
Однако REST не предлагает встроенных механизмов генерации кода, поэтому разработчики должны использовать дополнительные инструменты сторонних производителей, если им нужна эта функция.
Двунаправленная трансляция данных
gRPC обеспечивает двунаправленную потоковую передачу данных. Это означает, что и клиент, и сервер могут одновременно посылать и получать несколько запросов и ответов в рамках одного соединения.
REST не имеет этой функции.
Когда использовать gRPC, а когда – REST
В настоящее время REST является самой популярной архитектурой API для веб-сервисов и микросервисных архитектур. Популярность REST обусловлена простотой реализации и отображения структуры данных, а также удобством чтения и гибкостью. Начинающим программистам несложно начать разрабатывать интерфейсы RESTful API для своих приложений, будь то для веб-сервисов или внутренних микросервисов.
Примеры использования REST API:
- Веб-архитектуры.
- Общедоступные интерфейсы API для легкого понимания внешними пользователями.
- Простой обмен данными.
Система gRPC, в отличие от REST, была разработана специально для того, чтобы дать разработчикам возможность создавать высокопроизводительные API для микросервисных архитектур в распределенных центрах обработки данных. Она лучше подходит для внутренних систем, требующих потоковой передачи данных в реальном времени и загрузки больших объемов информации. gRPC также хорошо подходит для микросервисных архитектур на нескольких языках программирования, для которых API вряд ли будет меняться со временем.
gRPC API лучше использовать в следующих случаях:
- Создание высокопроизводительных систем.
- Загрузка больших данных.
- Разработка приложений реального времени или потоковых приложений.
Заметка о разработке сетевого программного обеспечения
Хотя HTTP является основным веб-протоколом, существуют разные версии HTTP, которые в разной степени используются в веб-браузерах и веб-серверах.
gRPC API всегда использует версию HTTP 2, а REST API обычно – версию HTTP 1.1, которая отличается от протокола HTTP. Несмотря на то, что версия HTTP 2 стала общепринятым веб-протоколом, она не имеет универсальной поддержки браузеров, в отличие от HTTP 1.1. Такая ограниченная поддержка может сделать gRPC менее привлекательным вариантом для разработчиков, желающих обеспечивать работу веб-приложений.
Краткое описание различий gRPC и REST
| gRPC API |
API REST |
|
| Что это |
Система для создания и использования API на основе модели связи RPC «клиент-сервер». |
Набор правил, определяющих структурированный обмен данными между клиентом и сервером. |
| Подход к проектированию |
Сервис-ориентированный дизайн. Клиент запрашивает у сервера услугу или функцию, которая может затрагивать ресурсы сервера или нет. |
Объектно-ориентированный дизайн. Клиент запрашивает у сервера создание, совместное использование или модификацию ресурсов. |
| Коммуникационная модель |
Существует несколько вариантов: унарный, один сервер – много клиентов, один клиент – много серверов, много клиентов – много серверов. |
Унарный. Один клиент взаимодействует с одним сервером. |
| Реализация |
Для работы требуется программное обеспечение gRPC как со стороны клиента, так и со стороны сервера. |
Его можно внедрять в самых разных форматах без стандартного программного обеспечения. |
| Доступ к данным |
Сервисные (функциональные) вызовы. |
Существует несколько адресов в виде URL для определения ресурсов. |
| Объем возвращенных данных |
В фиксированном возвращаемом типе сервиса, определенном в файле Protocol Buffer. |
В фиксированной структуре (обычно в формате JSON), определенной сервером. |
| Взаимозависимость «клиент-сервер» |
Сильная. И клиенту, и серверу нужен один и тот же файл Protocol Buffer, определяющий формат данных. |
Слабая. Клиент и сервер не знают о внутренних данных. |
| Автоматическая генерация кода |
Встроенная функция. |
Необходимо подключать сторонние инструменты. |
| Двунаправленная трансляция данных |
Присутствует. |
Отсутствует. |
| Лучше всего подходит для |
Высокопроизводительных микросервисных архитектур или архитектур с большим объемом данных. |
Простых источников данных с четко определенными ресурсами. |
Как AWS обеспечивает соответствие вашим требованиям к gRPC и REST?
Amazon Web Services (AWS) предлагает ряд сервисов и инструментов, с помощью которых разработчики API могут создавать, запускать современные приложения и сервисы на основе API и управлять ими. Дополнительные сведения см. в статье о создании современных приложений на AWS.
Ниже приведены инструменты AWS, которые могут удовлетворить ваши требования к API.
- Amazon API Gateway предоставляет разработчикам возможность создавать, публиковать API и управлять ими в любом масштабе. С помощью этого инструмента можно создавать RESTful API, оптимизированные для контейнерных микросервисных архитектур и веб-приложений.
- Elastic Load Balancing (ELB) распределяет сетевой трафик для улучшения масштабируемости приложений. Этот инструмент может маршрутизировать и балансировать трафик gRPC между микросервисами или клиентами и службами с поддержкой gRPC, что позволяет легко внедрять управление трафиком gRPC в архитектуры без изменения базовой инфраструктуры клиентов или их сервисов.
- Amazon Virtual Private Cloud (Amazon VPC) Lattice – это сетевой сервис приложений, который обеспечивает постоянное подключение, мониторинг и защиту связи между сервисами. Он автоматически масштабирует вычислительные и сетевые ресурсы для поддержки рабочих нагрузок HTTP, HTTPS и gRPC с высокой пропускной способностью.
Создайте аккаунт прямо сейчас и начните работу с gRPC и REST на AWS.
