Я читаю это объяснение GRPC, и эта диаграмма представляет интерес:
Как работает транспортный слой? Если это по сети... почему она называется RPC? Что еще более важно, как это отличается от REST, который реализует API для уровня обслуживания (класс в клиенте, который имеет методы, которые делают HTTP-запрос)?
Транспортный уровень работает с использованием протокола HTTP/2 поверх TCP/IP. Он позволяет использовать более низкие задержки (более быстрые) соединения, которые могут использовать одно соединение от клиента к серверу (что обеспечивает более эффективное использование соединения и может привести к более эффективному использованию ресурсов сервера.
HTTP/2 также поддерживает двунаправленную связь и асинхронную связь. Таким образом, сервер может эффективно связаться с клиентом для отправки сообщений (асинхронный ответ/уведомления и т.д.)
Хотя REST и gRPC могут создавать заглушки клиент/сервер (используя что-то вроде swagger для REST), REST имеет ограниченный набор первичных "функциональных" вызовов (или глаголов):
+-----------+----------------+ | HTTP Verb | CRUD | +-----------+----------------+ | GET | Read | | PUT | Update/Replace | | PATCH | Update/Modify | | DELETE | Delete | +-----------+----------------+
тогда как gRPC вы можете определять любые вызовы функций, включая синхронные/асинхронные, однонаправленные/двунаправленные (потоки) и т.д.
Используя gRPC, клиент делает вызов локальному методу. Для программиста, похоже, вы делаете локальный вызов, но базовый уровень (автогенерированный клиентский заглушка) отправляет вызов на сервер. Для сервера он выглядит так, как его метод вызывался локально.
gRPC заботится обо всех базовых сантехниках и упрощает парадигму программирования. Однако для некоторых посвященных пуристов REST это может показаться чрезмерным усложнением. YMMV
Самым большим преимуществом gRPC над REST является поддержка HTTP/2 над дедушкой HTTP 1.1. Тогда самым большим преимуществом HTTP/2 по HTTP 1.1 является: "HTTP/2 позволяет серверу" нажимать "контент"...
О, МОЙ БОГ. Пожалуйста, прекратите распространять неверную информацию.
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, et. Все они больше похожи на хаки - хаки поверх HTTP для туннелирования сервисов в стиле RPC через HTTP, для обхода ограничений межсетевого экрана и промежуточного ящика. Это не обязательно плохо. Иногда вам может понадобиться сервис в стиле RPC вместо сервиса REST, и мы должны жить в мире, где промежуточные блоки трудно заменить.
Если вам все лень читать реальное определение REST: https://www.ics.uci.edu/~fielding/pubs/dis Диссертация /rest_arch_style.htm
Там всегда TL;DR; версия в википедии:
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-бокса сейчас..;)