Comprendre gRPC, OpenAPI et REST, et quand les utiliser dans la conception d’API (2020)

Gestion des API

gRPC et REST : comprendre gRPC, OpenAPI et REST dans la conception d’API et savoir quand les utiliser

• Modèles de conception d’API : la conception d’API repose principalement sur deux modèles, RPC et REST. La plupart des API modernes sont implémentées sur le protocole HTTP.
• gRPC : technologie d’implémentation d’API RPC utilisant HTTP 2.0 comme protocole de transport. Google et d’autres utilisent largement des API qui combinent les idées de RPC et de HTTP.
• Trois principales façons d’utiliser HTTP :
  1. REST : le client utilise telle quelle l’URL fournie par le serveur, sans avoir besoin d’en comprendre le format.
  2. gRPC : utilise HTTP/2, mais HTTP n’est pas exposé au concepteur d’API.
  3. OpenAPI : le client appelle l’API à l’aide de modèles de chemin d’URL.

REST

• Caractéristiques : le client n’a pas besoin de comprendre le format des URL, et celles-ci ne font pas partie de la spécification de l’API.
• Avantages : bénéficie des atouts du Web, comme la stabilité, la cohérence et l’universalité. Le modèle orienté entités est plus simple et plus facile à comprendre.

gRPC

• Caractéristiques : utilise HTTP/2, mais les détails de HTTP sont masqués. Le client utilise l’API en appelant des procédures et en transmettant des paramètres.
• Avantages : permet de générer facilement des bibliothèques de programmation côté client et offre de bonnes performances.

OpenAPI

• Caractéristiques : l’API est appelée à l’aide de modèles de chemin d’URL, et le client doit comprendre le format des URL.
• Avantages : l’accès à l’API est possible avec les seules technologies HTTP standard. Il est possible de générer des bibliothèques de programmation côté client.

Comparaison entre gRPC et OpenAPI

• Points communs : tous deux peuvent être utilisés comme langage de définition d’interface RPC (IDL).
• Différences : gRPC masque les détails de HTTP, tandis qu’OpenAPI les expose.

Avantages de REST

• Modèle orienté entités : plus simple, plus facile à comprendre et stable dans le temps.

Utilisation d’OpenAPI

• Définition des chemins : l’API est définie à l’aide de chemins et de méthodes HTTP.

Avantages et inconvénients d’OpenAPI

• Avantages : proche du modèle RPC, donc familier pour les programmeurs. Peut être mappé sur des requêtes HTTP.
• Inconvénients : concevoir les détails HTTP demande beaucoup d’efforts.

Avantages de gRPC

• Implémentation simple : l’implémentation côté serveur est simple, et les bibliothèques côté client peuvent être facilement générées.
• Performances : efficace grâce à l’utilisation de charges utiles binaires.

Inconvénients de gRPC

• Nécessite des logiciels spécifiques : des logiciels spécifiques sont nécessaires côté client comme côté serveur.
• Fonctionnalités de proxy limitées : contrairement à une API HTTP, il est difficile d’étendre ou de modifier les fonctionnalités au niveau d’un proxy.

Conclusion

• Choix de la conception d’API : il faut choisir entre REST, OpenAPI et gRPC en tenant compte des avantages et inconvénients de chacun.
• Points à considérer pour l’usage de gRPC : gRPC est avantageux pour les API internes ou lorsque les clients n’ont pas besoin d’adopter eux-mêmes la technologie gRPC.

[GN⁺]

Discussion sur Hacker News

• Je regrette de ne pas avoir évité d’apprendre gRPC. J’ai passé énormément de temps en débogage et en ajustements de configuration

  • gRPC est censé masquer la complexité interne, mais en pratique il demande beaucoup de débogage et de réglages
  • J’ai perdu beaucoup de temps à cause du plugin Maven, des problèmes de compatibilité avec HTTP2 et des problèmes de pare-feu
  • La documentation est médiocre, et il était difficile de rendre les messages d’erreur observables

• Je construis des API depuis longtemps et j’ai utilisé gRPC ainsi que HTTP/REST

  • Je trouve étrange de distinguer OpenAPI et REST comme s’il s’agissait de deux choses opposées
  • OpenAPI est une manière de documenter le fonctionnement d’une API HTTP, et peut représenter une API RESTful
  • gRPC est un mécanisme RPC qui échange des protocol buffers
  • gRPC est efficace, mais pas aussi puissant que les bibliothèques HTTP

• J’ai travaillé dans une FAANG, et je pense que gRPC est utile pour le routage de services internes

  • Les protocoles RPC permettent de travailler à grande échelle et à haute vitesse
  • En revanche, je ne l’utiliserais pas pour des clients ni pour le web

• À moins de faire du streaming bidirectionnel, je pense que gRPC est une perte de temps

  • Il faut beaucoup de middleware pour faire des appels RPC entre des services implémentés dans différents langages

• Dans un projet utilisant gRPC, nous l’avions adopté pour des raisons de performance, mais nous sommes passés à une API JSON

  • Nous manquions d’expérience avec gRPC, et le projet a échoué à cause de plusieurs problèmes

• En utilisant connectrpc, je corrige les problèmes de gRPC

  • buf.build permet d’importer facilement des fichiers proto tiers
  • La génération automatique de SDK est extrêmement utile

• Je pense que l’expérience de développement avec gRPC est pire qu’avec REST

  • Il faut des outils supplémentaires, et le code client généré est complexe

• Roy Fielding a mentionné qu’avec une API REST, il suffit de connaître l’URI initial et les types de médias standardisés

• Je n’aime pas utiliser gRPC à l’intérieur d’un data center

  • Les performances ne sont pas si élevées, et la qualité des clients open source est faible
  • Pour les API web, je préfère la lisibilité du JSON, même s’il y a des problèmes d’incohérence de types

• J’ai eu le sentiment que gRPC est difficile d’accès en dehors de Google

  • Le client gRPC JS est lourd et opaque
  • Par rapport à la simplicité de REST, je pense que son exécution a été mal conçue