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

enter image description here

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)?

97
Jwan622 28 avril 2017 à 17:14

3 réponses

Meilleure réponse

La couche de transport fonctionne en utilisant HTTP / 2 en plus de TCP / IP. Il permet des connexions à latence plus faible (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):

+-----------+----------------+
| HTTP Verb |      CRUD      |
+-----------+----------------+
| GET       | Read           |
| PUT       | Update/Replace |
| PATCH     | Update/Modify  |
| DELETE    | Delete         |
+-----------+----------------+

Tandis 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

102
Acumenus 19 juin 2018 à 23:30

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) via 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" en plus de HTTP / x.x, 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 ..;)

40
Increasingly Idiotic 9 mars 2019 à 05:26

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» ...

4
Denis Wang 22 sept. 2017 à 13:32