Share
L'API REST est depuis longtemps un pilier de la programmation Web. Mais récemment, la GRPC a commencé à empiéter sur son territoire. Il s'avère qu'il existe de très bonnes raisons pour cela. Dans ce tutoriel, vous en apprendrez plus sur les tenants et les aboutissants de gRPC et sur sa comparaison avec REST..
Une des plus grandes différences entre REST et gRPC est le format de la charge utile. Les messages REST contiennent généralement JSON. Ce n'est pas une exigence stricte, et en théorie, vous pouvez envoyer n'importe quoi comme réponse, mais dans la pratique, tout l'écosystème REST, y compris les outils, les meilleures pratiques et les tutoriels, est axé sur JSON. Il est prudent de dire que, à de très rares exceptions près, les API REST acceptent et renvoient des fichiers JSON..
En revanche, gRPC accepte et renvoie les messages Protobuf. Je parlerai plus tard de la frappe puissante, mais du point de vue des performances, Protobuf est un format très efficace et complet. JSON, en revanche, est un format textuel. Vous pouvez compresser JSON, mais vous perdez l'avantage d'un format de texte auquel vous pouvez facilement vous attendre..
Comparons les protocoles de transfert utilisés par REST et par gRPC. Comme indiqué précédemment, REST dépend fortement de HTTP (généralement HTTP 1.1) et du modèle requête-réponse. Par ailleurs, gRPC utilise le nouveau protocole HTTP / 2..
Il existe plusieurs problèmes qui affectent HTTP 1.1 que HTTP / 2 corrige. Voici les principaux.
HTTP 1.0 RFC 1945 est une RFC de 60 pages. HTTP 1.1 était initialement décrit dans le document RFC 2616, qui contient jusqu'à 176 pages. Cependant, plus tard, l'IETF l'a divisé en six documents différents - RFC 7230, 7231, 7232, 7233, 7234 et 7235 - avec un nombre de pages combinées encore plus élevé. HTTP 1.1 autorise de nombreuses pièces facultatives qui contribuent à sa taille et à sa complexité..
La tendance des pages Web est d'augmenter à la fois la taille totale de la page (1,9 Mo en moyenne) et le nombre d'objets de la page nécessitant des requêtes individuelles. Étant donné que chaque objet nécessite une requête HTTP distincte, cette multiplication d’objets augmente considérablement la charge sur les serveurs Web et ralentit les temps de chargement des pages pour les utilisateurs..
HTTP 1.1 est sensible à la latence. Une négociation TCP est requise pour chaque requête individuelle, et un plus grand nombre de requêtes a un impact significatif sur le temps nécessaire au chargement d'une page. L’amélioration continue de la bande passante disponible ne résout pas ces problèmes de latence dans la plupart des cas.
La limitation du nombre de connexions au même domaine (auparavant 2 à 8 fois aujourd'hui) réduit considérablement la possibilité d'envoyer plusieurs demandes en parallèle..
Avec le traitement en pipeline HTTP, vous pouvez envoyer une demande en attendant la réponse à une demande précédente, créant ainsi une file d'attente. Mais cela introduit d'autres problèmes. Si votre demande reste bloquée derrière une demande lente, votre temps de réponse en souffrira..
Il existe d'autres problèmes, tels que les performances et les pénalités en ressources lors du changement de ligne. Pour le moment, le traitement en pipeline HTTP n'est pas largement activé.
HTTP / 2, issu de SPDY de Google, conserve les principes de base et les paradigmes de HTTP:
Accentsconagua
http: // et https: // Schémas d'URLMais les parties optionnelles de HTTP 1.1 ont été supprimées.
Pour traiter le protocole de négociation en raison du schéma d'URL partagé, il existe un en-tête de mise à niveau. En outre, voici un choc pour vous: le protocole HTTP / 2 est binaire! Si vous connaissez les protocoles Internet, sachez que les protocoles textuels sont considérés comme les meilleurs, car ils sont plus faciles à dépanner et à créer manuellement des requêtes. Mais, dans la pratique, la plupart des serveurs utilisent de nos jours le cryptage et la compression. Le cadrage binaire contribue dans une large mesure à réduire la complexité de la gestion des cadres dans HTTP 1.1..
Cependant, l’amélioration majeure de HTTP / 2 réside dans le fait qu’il utilise des flux multiplexés. Une seule connexion HTTP / 2 TCP peut prendre en charge de nombreux flux bidirectionnels. Ces flux peuvent être entrelacés (pas de mise en file d'attente) et plusieurs demandes peuvent être envoyées simultanément sans qu'il soit nécessaire d'établir de nouvelles connexions TCP pour chacune d'entre elles. De plus, les serveurs peuvent désormais envoyer des notifications aux clients via la connexion établie (HTTP / 2 push)..
REST est une API intéressante. Il est construit très étroitement sur HTTP. Il n'utilise pas uniquement HTTP comme transport, mais englobe toutes ses fonctionnalités et crée un cadre conceptuel cohérent. En théorie, ça sonne bien. En pratique, il a été très difficile de mettre en œuvre correctement REST.
Ne vous méprenez pas, REST a été et connaît un grand succès, mais la plupart des implémentations n'adhèrent pas pleinement à la philosophie REST et n'utilisent qu'un sous-ensemble de ses principes. La raison en est qu’il est en fait assez difficile de mapper la logique et les opérations de l’entreprise dans le monde strict de REST..
Le modèle conceptuel utilisé par gRPC consiste à disposer de services dotés d'interfaces claires et de messages structurés pour les demandes et les réponses. Ce modèle traduit directement des concepts de langage de programmation tels que les interfaces, les fonctions, les méthodes et les structures de données. Cela permet également à gRPC de générer automatiquement des bibliothèques clientes pour vous..
REST prend en charge uniquement le modèle requête-réponse disponible dans HTTP 1.x. Mais gRPC tire pleinement parti des fonctionnalités de HTTP / 2 et vous permet de diffuser des informations en permanence. Il y a plusieurs types de streaming.
Le serveur renvoie un flux de réponses après avoir reçu un message de demande client. Après avoir renvoyé toutes ses réponses, les détails de l’état du serveur et les métadonnées de fin facultatives sont renvoyés pour se terminer côté serveur. Le client termine une fois qu'il a toutes les réponses du serveur.
Le client envoie un flux de plusieurs demandes au serveur. Le serveur renvoie une seule réponse, généralement, mais pas nécessairement, après avoir reçu toutes les demandes du client, avec les détails de son statut et les métadonnées de fin facultatives..
Dans ce scénario, le client et le serveur s'échangent des informations sous une forme à peu près libre (à l'exception du client qui lance la séquence). Finalement, le client ferme la connexion.
Le paradigme REST n'impose aucune structure pour la charge utile échangée. C'est typiquement JSON. Les consommateurs ne disposent pas d'un mécanisme officiel pour coordonner le format des demandes et des réponses. Le JSON doit être sérialisé et converti dans le langage de programmation cible à la fois côté serveur et côté client. La sérialisation est une autre étape de la chaîne qui introduit la possibilité d’erreurs ainsi que de la surcharge des performances..
Le contrat de service gRPC contient des messages fortement typés qui sont automatiquement convertis de leur représentation Protobuf dans le langage de programmation de votre choix, à la fois sur le serveur et sur le client..
JSON, en revanche, est théoriquement plus flexible car vous pouvez envoyer des données dynamiques sans devoir vous conformer à une structure rigide..
La prise en charge de gRPC dans le navigateur n’est pas aussi avancée. Aujourd'hui, le gRPC est principalement utilisé pour des services internes qui ne sont pas exposés directement au monde..
Si vous souhaitez utiliser un service gRPC à partir d'une application Web ou d'un langage non pris en charge par gRPC, gRPC propose une passerelle API REST pour exposer votre service. Le plug-in de passerelle gRPC génère un serveur d'API REST à part entière avec un proxy inverse et une documentation Swagger..
Avec cette approche, vous perdez la plupart des avantages de gRPC, mais si vous devez fournir l'accès à un service existant, vous pouvez le faire sans implémenter votre service deux fois..
Dans le monde des microservices, le gRPC deviendra très vite dominant. Les avantages en termes de performances et la facilité de développement sont tout simplement trop beaux pour être ignorés. Cependant, ne vous y trompez pas, REST restera encore longtemps. Il excelle toujours pour les API exposées publiquement et pour des raisons de compatibilité descendante.
