Я читаю это объяснение GRPC, и эта диаграмма представляет интерес:
Как работает транспортный уровень? Если это по сети ... почему это называется RPC? Что еще более важно, чем это отличается от REST, который реализует API для уровня сервиса (класс в клиенте, у которого есть методы, выполняющие HTTP-запрос)?
Ответы:
Транспортный уровень работает с использованием HTTP / 2 поверх TCP / IP. Это обеспечивает более низкую задержку (более быстрые) соединения, которые могут использовать преимущества одного соединения от клиента к серверу (что позволяет более эффективно использовать соединение и может привести к более эффективному использованию ресурсов сервера.
HTTP / 2 также поддерживает двунаправленное и асинхронное соединение. Таким образом, сервер может эффективно связываться с клиентом для отправки сообщений (асинхронный ответ / уведомления и т. Д.)
Хотя и REST, и gRPC могут генерировать заглушки клиент / сервер (используя что-то вроде swagger для REST), REST имеет ограниченный набор основных вызовов функций (или глаголов):
+ ----------- + ---------------- + | HTTP-команда | CRUD | + ----------- + ---------------- + | ПОЛУЧИТЬ | Читать | | PUT | Обновить / заменить | | ПАТЧ | Обновить / изменить | | УДАЛИТЬ | Удалить | + ----------- + ---------------- +
тогда как gRPC вы можете определять любые типы вызовов функций, включая синхронные / асинхронные, однонаправленные / двунаправленные (потоки) и т. д.
Используя gRPC, клиент вызывает локальный метод. Программисту кажется, что вы выполняете локальный вызов, но базовый уровень (автоматически сгенерированная клиентская заглушка) отправляет вызов на сервер. Для сервера это выглядит так, как будто его метод был вызван локально.
gRPC берет на себя всю внутреннюю инфраструктуру и упрощает парадигму программирования. Однако некоторым преданным сторонникам REST это может показаться чрезмерным усложнением. YMMV
REST не требует JSON или HTTP / 1.1
Вы можете тривиально создать службу RESTful, которая отправляет сообщения protobuf (или что-то еще) через HTTP / 2.
Вы можете создавать службы RESTful, которые отправляют JSON через HTTP / 2.
Вы можете создавать сервисы RESTful, которые отправляют сообщения protobuf через HTTP / 1.1.
Службы RESTful не являются «взломом» поверх HTTP / xx, это службы, следующие фундаментальным принципам архитектуры, которые сделали любую версию HTTP успешной (например, кэшируемость запросов GET и возможность воспроизведения запросов PUT).
gRPC, SOAP и др. Все они больше похожи на хаки - хаки поверх HTTP для туннелирования служб в стиле RPC через HTTP, для обхода ограничений межсетевого экрана и промежуточного ящика. Это не обязательно плохо. Иногда вам может понадобиться служба в стиле RPC вместо службы REST, и мы должны жить в мире, где сложно заменить промежуточные блоки.
Если у вас нет времени ознакомиться с фактическим определением REST: https://www.ics.uci.edu/~fielding/pubs/dissis/rest_arch_style.htm
Всегда есть TLDR; версия в Википедии:
https://en.wikipedia.org/wiki/Representational_state_transfer
Если вам нужен сервис в стиле RPC, конечно, gRPC - отличный вариант. Если вы хотите жить в Интернете или хотите получить все преимущества службы стиля RESTful, создайте службу стиля RESTful. И если сериализовать / десериализовать данные в формате JSON в вашем успокаивающем сервисе слишком медленно, совершенно нормально использовать protobuf или что-то еще.
Если gRPC - это версия 2 чего-либо, это версия 2 SOAP. Не такой уж и ужасный, как SOAP.
И нет, вы не можете просто «вызвать любую функцию» в своем запросе GET и получить службу RESTful.
И последнее: если вы собираетесь использовать protobufs поверх службы RESTful, сделайте это правильно, используя заголовки типов контента и т. Д. Благодаря этому вы можете легко поддерживать как JSON, так и protobuf.
Сейчас выхожу из своего SOAP-бокса ..;)
Самым большим преимуществом gRPC перед REST является его поддержка HTTP / 2 по сравнению с дедушкой HTTP 1.1. Тогда самым большим преимуществом HTTP / 2 перед HTTP 1.1 является то, что HTTP / 2 позволяет серверу «проталкивать» контент ...