REST vs gRPC: quand dois-je choisir l'un plutôt que l'autre?
Je vois de plus en plus d'organisations logicielles utilisant gRPC dans leurs architectures orientées services, mais les gens utilisent également REST. Dans quels cas d'utilisation est-il judicieux d'utiliser gRPC et quand est-il logique d'utiliser REST pour la communication interservices?
Fait intéressant, je suis tombé sur des projets open source qui utilisent à la fois REST et gRPC. Par exemple, Kubernetes et Docker Swarm emploient tous gRPC dans une certaine mesure pour la coordination de cluster, mais exposent également REST API pour l'interfaçage avec les nœuds maître/leader. Pourquoi ne pas utiliser gRPC de haut en bas?
Une fois fait correctement, REST améliore l'évolutivité et l'évolutivité à long terme au détriment des performances et de la complexité accrue. REST est idéal pour les services qui doivent être développés et maintenus indépendamment, comme le Web lui-même. Le client et le serveur peuvent être couplés librement et changer sans se casser.
Les services RPC peuvent être plus simples et plus performants, au détriment de la flexibilité et de l'indépendance. Les services RPC sont idéaux dans les cas où le client et le serveur sont étroitement couplés et suivent le même cycle de développement.
Cependant, la plupart des services dits [REST ne suivent pas vraiment REST, car REST n'est devenu qu'un mot à la mode pour tout type d'API HTTP. En fait, la plupart des REST API sont si étroitement couplées qu'elles n'offrent aucun avantage par rapport à une conception RPC.
Cela étant, mes réponses quelque peu cyniques à votre question sont les suivantes:
Certaines personnes adoptent gRPC pour la même raison qu'elles ont adopté REST il y a quelques années: design-by-buzzword.
Beaucoup de gens réalisent que la façon dont ils implémentent REST équivaut à RPC de toute façon, alors pourquoi ne pas opter pour un framework RPC standard et l'implémenter correctement, au lieu d'insister sur de mauvaises implémentations REST?
REST est une solution aux problèmes qui apparaissent dans des projets qui s'étendent sur plusieurs organisations et qui ont des objectifs à long terme. Peut-être que les gens réalisent qu'ils n'ont pas vraiment besoin de REST et recherchent de meilleures options.
En fonction du gRPC future feuille de route , les gens continueront à migrer vers celui-ci et à laisser REST (via HTTP) "silencieux").
gRPC est plus pratique à bien des égards:
- Habituellement rapide (comme super rapide)
- (Presque) Pas de "dichotomie de conception" - quel est le bon point final à utiliser, quel est le bon verbe HTTP à utiliser, etc.
- Ne pas gérer le désordre désordre de sérialisation d'entrée/réponse car gRPC gère la sérialisation - encodage de données plus efficace et HTTP/2 qui accélère les choses avec le multiplexage requêtes sur une seule connexion et compression d'en-tête
- Définissez/Déclarez votre entrée/réponse et générez des clients fiables pour différentes langues (bien sûr, ceux qui sont "pris en charge", c'est un énorme avantage)
- Ensemble formalisé d'erreurs - ceci est discutable mais jusqu'à présent, elles sont plus directement applicables aux cas d'utilisation de l'API que les codes d'état HTTP
Dans tous les cas, vous devrez également gérer tous les problèmes de gRPC, car rien dans ce monde n'est infaillible, mais jusqu'à présent, il "semble mieux" que REST - et l'a effectivement prouvé.
Je pense que vous pouvez avoir le meilleur des deux mondes. Dans tous les cas, gRPC suit en grande partie la sémantique HTTP (sur HTTP/2) mais autorise explicitement le streaming en duplex intégral, s'écartant des conventions typiques REST car il utilise statique chemins pour des raisons de performances lors de la répartition des appels, car l'analyse des paramètres d'appel à partir des chemins - les paramètres de requête et le corps de la charge utile ajoutent de la latence et de la complexité.
La promesse de REST a toujours été une interface uniforme . Un client idéal REST serait en mesure de parler à un large éventail de Ressources RESTful, même celles qui n'existaient pas lors du codage du client.
Malheureusement, cet idéal ne s’est jamais vraiment concrétisé, sauf dans le cas original de REST - le World Wide Web de documents lisibles par l’homme.
À ce stade, la plupart des interfaces qui s'appellent "RESTful" sont en réalité une sorte de RPC baroque, où les données de demande et de réponse sont étalées sur les méthodes, les chaînes de requête, les en-têtes, les codes d'état, les charges utiles, le tout dans une variété de formats fragiles.
La plupart de l'uniformité des interfaces "RESTful" d'aujourd'hui est dans la tête des développeurs. Ils "savent" que POST /orders/ va probablement ajouter une nouvelle commande. Mais ils doivent encore programmer leurs clients pour qu'ils "sachent" que, pour chaque API à laquelle ils parlent, ils font souvent beaucoup d'erreurs.
Pourtant, il existe une certaine uniformité qui peut être utile dans le code. Par exemple, si vous disposez d'une API "RESTful", vous pouvez souvent y ajouter une couche de mise en cache transparente et finement réglable presque gratuitement. Ceci est possible car les messages HTTP (sémantiquement corrects) contiennent déjà toutes les informations standardisées nécessaires à la mise en cache: méthode de requête, URL, code d'état, Cache-Control, Vary et tout ça. Dans gRPC, vous devez rouler votre propre cache.
Mais la vraie raison de la domination actuelle de "REST" n'est pas ce genre de petites dérogations. C’est vraiment juste le succès du World Wide Web. À un moment donné de l'histoire, il est apparu que tout le monde avait déjà un serveur HTTP flexible et performant (pour servir son site Web) et un client HTTP solide (pour voir ledit site), donc quand les gens ont commencé à ajouter des ressources lisibles par machine, il était tout simplement plus facile et moins cher de s'en tenir aux mêmes méthodes HTTP. Ils ont utilisé des méthodes HTTP, des en-têtes et des codes d'état, car c'est ce que leurs serveurs Web ont déjà compris et enregistré. Des outils comme PHP leur ont permis de le faire sans aucun frais de déploiement sur leurs sites Web habituels.
Si l'uniformité et l'alignement avec le World Wide Web ne sont pas importants pour vous, alors RPC est un choix architectural éprouvé et vrai, et gRPC est une implémentation solide qui peut vous éviter des ennuis, comme l'explique ɐuıɥɔɐɯ.