Чем GRPC отличается от REST?

98

Я читаю это объяснение GRPC, и эта диаграмма представляет интерес:

введите описание изображения здесь

Как работает транспортный уровень? Если это по сети ... почему это называется RPC? Что еще более важно, чем это отличается от REST, который реализует API для уровня сервиса (класс в клиенте, у которого есть методы, выполняющие HTTP-запрос)?

Jwan622
источник
20
«Если это по сети ... почему это называется RPC» - Потому что RPC - это удаленный вызов процедуры, а «удаленный» может полностью означать «на другом хосте».
weirdan

Ответы:

104

Транспортный уровень работает с использованием HTTP / 2 поверх TCP / IP. Это обеспечивает более низкую задержку (более быстрые) соединения, которые могут использовать преимущества одного соединения от клиента к серверу (что позволяет более эффективно использовать соединение и может привести к более эффективному использованию ресурсов сервера.

HTTP / 2 также поддерживает двунаправленное и асинхронное соединение. Таким образом, сервер может эффективно связываться с клиентом для отправки сообщений (асинхронный ответ / уведомления и т. Д.)

Хотя и REST, и gRPC могут генерировать заглушки клиент / сервер (используя что-то вроде swagger для REST), REST имеет ограниченный набор основных вызовов функций (или глаголов):

+ ----------- + ---------------- +
| HTTP-команда | CRUD |
+ ----------- + ---------------- +
| ПОЛУЧИТЬ | Читать |
| PUT | Обновить / заменить |
| ПАТЧ | Обновить / изменить |
| УДАЛИТЬ | Удалить |
+ ----------- + ---------------- +

тогда как gRPC вы можете определять любые типы вызовов функций, включая синхронные / асинхронные, однонаправленные / двунаправленные (потоки) и т. д.

Используя gRPC, клиент вызывает локальный метод. Программисту кажется, что вы выполняете локальный вызов, но базовый уровень (автоматически сгенерированная клиентская заглушка) отправляет вызов на сервер. Для сервера это выглядит так, как будто его метод был вызван локально.

gRPC берет на себя всю внутреннюю инфраструктуру и упрощает парадигму программирования. Однако некоторым преданным сторонникам REST это может показаться чрезмерным усложнением. YMMV

ммкейб
источник
2
Итак, быстрый вопрос: в REST вы также можете вызывать любые функции. Например, в Rails я могу отправить запрос GET на конечную точку, которая не поддерживает RESTful, и сделать что-то помимо простого получения ресурса. Я могу исключить любую функцию из этой конечной точки, отличной от RESTful. Я также могу создавать службы в REST, которые кажутся вызывающими локальный метод, но на самом деле внутри них выполняется http-вызов конечной точки. Так что различия не так уж велики ... по крайней мере, на транспортном уровне. Или они?
Jwan622
2
REST / RESTful работает через HTTP, gRPC работает через HTTP / 2 (как WebSocket). Используя генератор кода из Swagger, можно сгенерировать клиентские и серверные заглушки для REST, gRPC использует прото-файл для генерации своих заглушек (мало чем отличается от старого подхода WSDL / SOAP). Файл proto определяет тип, поэтому сгенерированные заглушки клиент / сервер безопасны по типу. На мобильном устройстве соединение gRPC эффективно, поскольку оно может использовать один и тот же базовый сокет HTTP / 2 с любыми другими параллельными соединениями из мобильного приложения.
mmccabe
Вот хороший интро КПГР: medium.com/square-corner-blog/grpc-reaches-1-0-85728518393b Вот демо КПГР: github.com/mmcc007/go
mmccabe
1
Jwan622 и mmccabe: Используя библиотеку Superglue 2.1, я могу построить дом из яблок и апельсинов. В какой-то момент мы должны выбрать правильный инструмент для работы и всегда стремиться минимизировать сложность нашей программной системы. Помните, что удаление кода - это всегда оптимизация производительности;)
Мартин Андерссон,
4
С моей точки зрения, такие вещи, как RESTful API, всегда были «уловкой» для старых протоколов. Если появится что-то, что позволит мне использовать стек, более подходящий для современных языков, и при этом не зависеть от того, какой язык конкретно используется клиентом, И значительно повысить производительность, то я буду первым, кто присоединится к этому!
Мартин Андерссон
42

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-бокса ..;)

user2077221
источник
Вы имеете в виду, что службу RESTful нельзя создать с помощью gRPC?
Кевин С.
1
RTFM со ссылкой на диссертацию Филдинга был излишним, но в остальном получил большой отклик.
rmharrison
4

Самым большим преимуществом gRPC перед REST является его поддержка HTTP / 2 по сравнению с дедушкой HTTP 1.1. Тогда самым большим преимуществом HTTP / 2 перед HTTP 1.1 является то, что HTTP / 2 позволяет серверу «проталкивать» контент ...

Денис Ван
источник
1
Для проталкивания сервера не требуется HTTP / 2.
Робин Грин
Не могли бы Вы уточнить? Это вики, рассказывающая о HTTP / 2 Server Push: en.wikipedia.org/wiki/HTTP/2_Server_Push
Денис Ван
2
Извините, я имел в виду не HTTP 2 server push, я имел в виду потоковые ответы. Есть и другие способы потоковой передачи ответов, например, почтенный длинный опрос или веб-сокеты.
Робин Грин
1
Сервер gRPC не отправляет HTTP / 2 "push", а клиент gRPC игнорирует HTTP / 2 "push". Таким образом, преимущества gRPC, унаследованные от HTTP / 2, не должны включать "push".
user675693