En quoi GRPC est-il différent de REST?

98

Je lis cette explication de GRPC et ce diagramme est intéressant:

entrez la description de l'image ici

Comment fonctionne la couche de transport? Si c'est sur le réseau ... pourquoi s'appelle-t-il un RPC? Plus important encore, en quoi est-ce différent de REST qui implémente une API pour la couche de service (la classe dans le client qui a des méthodes qui font une requête http)?

rest grpc Jwan622
la source
20
«Si c'est sur le réseau ... pourquoi est-il appelé un RPC» - Parce que RPC est un appel de procédure à distance, et «distant» peut totalement signifier «sur un autre hôte».
weirdan

Réponses:

104

La couche de transport fonctionne en utilisant HTTP / 2 en plus de TCP / IP. Il permet des connexions à faible latence (plus rapides) qui peuvent tirer parti d'une connexion unique du client au serveur (ce qui permet une utilisation plus efficace de la connexion et peut entraîner une utilisation plus efficace des ressources du serveur.

HTTP / 2 prend également en charge la connectivité bidirectionnelle et la connectivité asynchrone. Il est donc possible pour le serveur de prendre efficacement contact avec le client pour envoyer des messages (réponse asynchrone / notifications, etc.)

Alors que REST et gRPC peuvent générer des stubs client / serveur (en utilisant quelque chose comme swagger pour REST), REST a un ensemble limité d'appels de `` fonction '' primaires (ou verbes):

+ ----------- + ---------------- +
| Verbe HTTP | CRUD |
+ ----------- + ---------------- +
| GET | Lire |
| PUT | Mettre à jour / remplacer |
| PATCH | Mettre à jour / modifier |
| DELETE | Supprimer |
+ ----------- + ---------------- +

alors que gRPC vous pouvez définir tout type d'appels de fonction, y compris synchrone / asynchrone, unidirectionnel / bidirectionnel (flux), etc.

À l'aide de gRPC, le client appelle une méthode locale. Pour le programmeur, il semble que vous effectuez un appel local, mais la couche sous-jacente (le stub client généré automatiquement) envoie l'appel au serveur. Pour le serveur, il semble que sa méthode a été appelée localement.

gRPC prend en charge toute la plomberie sous-jacente et simplifie le paradigme de programmation. Cependant, pour certains puristes REST dévoués, cela peut sembler une complication excessive. YMMV

mmccabe
la source
2
Donc, petite question: dans REST, vous pouvez également appeler n'importe quel type de fonction. Par exemple, dans Rails, je peux envoyer une requête GET à un point de terminaison qui n'est pas RESTful et faire quelque chose en plus d'obtenir une ressource. Je peux lancer vraiment n'importe quelle fonction à partir de ce point de terminaison non RESTful. Je peux également créer des services dans REST qui semblent appeler une méthode locale, mais qui font vraiment un appel http à un point final. Les différences ne sont donc pas si grandes ... du moins sur la couche de transport. Ou sont-ils?
Jwan622
2
REST / RESTful s'exécute sur HTTP, gRPC s'exécute sur HTTP / 2 (comme un WebSocket). En utilisant un générateur de code de Swagger, il est possible de générer des stubs client et serveur pour REST, gRPC utilise un fichier proto pour générer ses stubs (un peu comme l'ancienne approche WSDL / SOAP). Le fichier proto définit le type, de sorte que les stubs client / serveur générés sont de type sécurisé. Sur un appareil mobile, la connexion gRPC est efficace car elle peut partager le même socket HTTP / 2 sous-jacent avec toutes les autres connexions simultanées de l'application mobile.
mmccabe
Voici une belle introduction à gRPC: medium.com/square-corner-blog/grpc-reaches-1-0-85728518393b Voici une démo de gRPC: github.com/mmcc007/go
mmccabe
1
Jwan622 et mmccabe: En utilisant la bibliothèque Superglue 2.1, je peux construire une maison avec des pommes et des oranges. À un moment donné, nous devons choisir le bon outil pour le travail et chercher toujours à minimiser la complexité de notre système logiciel. N'oubliez pas que la suppression du code est toujours une optimisation des performances;)
Martin Andersson
4
De mon point de vue, des trucs comme les API RESTful ont toujours été un "hack" à utiliser avec d'anciens protocoles. Si quelque chose arrive qui me permet d'utiliser une pile plus adaptée aux langues modernes tout en restant indépendant de la langue utilisée par un client ET d'augmenter considérablement les performances, alors je vais être la première personne à sauter dans le train en marche!
Martin Andersson
42

REST ne nécessite ni JSON ni HTTP / 1.1

Vous pouvez facilement créer un service RESTful qui envoie des messages protobuf (ou autre) sur HTTP / 2

Vous pouvez créer des services RESTful qui envoient JSON sur HTTP / 2

Vous pouvez créer des services RESTful qui envoient des messages protobuf via HTTP / 1.1

Les services RESTful ne sont pas un "hack" au-dessus de HTTP / xx, ce sont des services suivant les principes architecturaux fondamentaux qui ont permis à toute version de HTTP de réussir (comme la capacité de cache des requêtes GET et la rejouabilité des requêtes PUT).

gRPC, SOAP, et. tous ressemblent plus à des hacks - des hacks en plus de HTTP pour tunneler des services de style RPC sur HTTP, pour contourner les restrictions de pare-feu et de boîtier de médiation. Ce n'est pas nécessairement une mauvaise chose. Parfois, vous voudrez peut-être un service de style RPC au lieu d'un service REST, et nous devons vivre dans un monde où les boîtiers de médiation sont difficiles à remplacer.

Si vous n'avez pas le temps de lire la définition réelle de REST: https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Il y a toujours le TLDR; version sur wikipedia:

https://en.wikipedia.org/wiki/Representational_state_transfer

Si vous avez besoin d'un service de style RPC, bien sûr, gRPC est génial. Si vous voulez vivre sur le Web ou si vous voulez tous les avantages d'un service de style RESTful, créez un service de style RESTful. Et s'il est trop lent de sérialiser / désérialiser les données au format JSON dans votre service reposant, il est parfaitement acceptable d'utiliser protobuf ou autre.

Si gRPC est une version 2 de quoi que ce soit, c'est une version 2 de SOAP. Un qui n'est pas terrible, comme SOAP.

Et, non, vous ne pouvez pas simplement "appeler n'importe quelle fonction" dans votre requête GET et avoir un service RESTful.

Une dernière chose: si vous comptez utiliser protobufs sur un service RESTful, faites-le correctement, en utilisant les en-têtes de type de contenu, etc. Avec cela, vous pouvez facilement supporter à la fois JSON ET protobuf.

Quitter ma boîte SOAP maintenant ..;)

user2077221
la source
Voulez-vous dire qu'un service RESTful ne peut pas être créé à l'aide de gRPC?
Kevin S
1
La RTFM citant la thèse de Fielding était exagérée, mais sinon une excellente réponse.
rmharrison
4

Le plus grand avantage de gRPC par rapport à REST est sa prise en charge de HTTP / 2 sur le grand-père HTTP 1.1. Ensuite, le plus grand avantage de HTTP / 2 par rapport à HTTP 1.1 est que «HTTP / 2 permet au serveur de« pousser »du contenu» ...

Denis Wang
la source
1
Le serveur push n'a pas besoin de HTTP / 2.
Robin Green
Pourriez-vous être plus précis? Voici le wiki qui parle de HTTP / 2 Server Push: en.wikipedia.org/wiki/HTTP/2_Server_Push
Denis Wang
2
Désolé, je ne parlais pas de push de serveur HTTP 2, mais de réponses en continu. Il existe d'autres moyens de diffuser des réponses en continu, comme le long sondage, ou les websockets, par exemple.
Robin Green
1
Le serveur gRPC n'envoie pas HTTP / 2 "push et le client gRPC ignore" push "HTTP / 2. Les avantages de gRPC hérités de HTTP / 2 ne devraient donc pas inclure" push ".
user675693