gRPC contre REST

Dans le Grand Atlas d’Internet, les interfaces de programmation des applications (API) sont les routes qui relient les villes, les plages et d’autres destinations. Les API permettent aux applications logicielles de communiquer entre elles pour échanger des données, des caractéristiques et des fonctionnalités. Un rapport Imperva de 2023 a révélé qu’environ 71 % du trafic Internet était constitué d’appels API, signe que cette technologie est essentielle pour le fonctionnement des applications et des entreprises modernes.

Il n’est pas étonnant que comprendre comment créer une API soit une compétence fondamentale pour la plupart des développeurs. Mais, comme il convient à une infrastructure aussi importante, il existe de multiples variétés.

Pour prolonger notre métaphore, une autoroute à 12 voies n’est pas « meilleure » qu’une route à une seule voie. Cette autoroute détruirait le tissu d’un quartier urbain et cette route de surface serait un désastre dans une zone à fort trafic. Différents styles d’architecture pour la création d’API, tels que REST et gRPC, fonctionnent de la même manière : chacun a des points forts et des points faibles, et il est essentiel de les comprendre pour créer une infrastructure saine.

Le Representational State Transfer, ou REST, est un ensemble de principes de conception (ou contraintes architecturales) : interface uniforme, découplage client-serveur, état sans état, mise en cache, architecture système en couches et code à la demande (facultatif). Les API créées selon ces principes sont appelées API REST, ou API RESTful.

Les API REST peuvent utiliser divers langages de programmation et formats de données, à condition qu’ils respectent les principes REST. Il s’agit de la manière la plus courante de créer une API.

Les API REST utilisent des requêtes HTTP (également appelées méthodes HTTP) telles que GET, POST, PUT et DELETE pour exécuter des fonctions de base de données standard. Ces opérations sont utilisées pour créer, lire, mettre à jour et supprimer des enregistrements de ressources et sont souvent appelées « CRUD ». Les ressources côté serveur sont identifiées par des URL appelées points de terminaison.

Par exemple, une API REST utilise une requête GET pour récupérer un enregistrement. Une requête POST crée un nouvel enregistrement. Une requête PUT met à jour un enregistrement et une requête DELETE en supprime un. Toutes les méthodes HTTP peuvent être utilisées dans les appels API. Une API REST bien conçue est similaire à un site web exécuté dans un navigateur web avec une fonctionnalité HTTP intégrée.

Les informations sur les ressources peuvent être fournies à un client dans de nombreux formats de messagerie, notamment JavaScript Object Notation (JSON), HTML, XLT, Python, PHP ou en texte brut. JSON est populaire parce qu’il est lisible à la fois par l’homme et par la machine et qu’il ne dépend pas d’un langage de programmation.

En savoir plus sur REST et GraphQL

Prise en charge des navigateurs : étant donné que les API REST utilisent le protocole HTTP/1.1 et les méthodes HTTP standard, ainsi que des formats tels que XML et JSON, elles sont compatibles avec les navigateurs. 

Facilité d’utilisation : en raison de sa simplicité et de sa popularité, REST est largement considéré comme plus facile à comprendre, en particulier pour les débutants. Les outils, tutoriels et guides sont nombreux sur GitHub et ailleurs.

Flexibilité : les API REST sont considérées comme ayant un couplage lâche entre le client et le serveur. Cette flexibilité permet des changements plus simples et plus rapides : une modification peut être apportée à l’un des deux côtés sans qu’il soit nécessaire de modifier l’autre.

Écosystème robuste : les API REST disposent d’un nombre important d’outils et d’un large support et d’une documentation. La spécification OpenAPI, ou OAS, par exemple, fournit une définition standard des paramètres et des capacités d’une API REST dans le secteur. La dernière version d’OAS, OAS 3.1, inclut une compatibilité totale avec le schéma JSON, une identification standardisée qui utilise l’identifiant SPDX, etc.

Dépendance sur HTTP/1.1 : Si l’utilisation par REST du protocole HTTP/1.1 permet une prise en charge universelle des navigateurs et une certaine personnalisation des en-têtes, elle prive également les API REST de certains des avantages du protocole HTTP/2, plus récent. Parmi les avantages manquants figure le flux bidirectionnel, REST ne prend en charge que le flux unaire, dans lequel une demande est suivie d’une réponse.

Plus lent et moins efficace : comme pour HTTP/1.1, La dépendance de REST à l’égard de formats tels que XML et JSON présente des inconvénients et des avantages. Ces formats sont lisibles par l’homme, ce qui est bien, mais ce sont aussi des fichiers relativement volumineux, ce qui ralentit la transmission.

Nécessite des outils supplémentaires : l’écosystème de REST est peut-être robuste, mais il doit l’être, car certaines fonctionnalités ne sont pas intégrées à l’architecture. La génération de code, par exemple, est disponible sous la forme de plug-ins pour REST, mais cela reste une étape supplémentaire, avec une complication supplémentaire.

gRPC est un cadre d’exigences open source que Google a initialement développé en tant qu’implémentation spécifique de l’appel de procédure à distance (remote procedure call, ou RPC). Il est désormais géré par la Cloud Native Computing Foundation (CNCF).

gRPC pourrait ou non signifier « Google Remote Procedure Call », car les développeurs insistent sur le fait qu’il pourrait plutôt s’agir de « gRPC Remote Procedure Call » ou diverses autres possibilités. Quoi qu’il en soit, gRPC, comme d’autres RPC, permet aux appels à distance d’apparaître et de fonctionner comme des appels locaux.

En tant que modèle d’interaction client/serveur, RPC est souvent utilisé dans le développement d’API. Dans un modèle RPC, le client interagit avec un intermédiaire communément appelé stub, qui convertit les données à transmettre et, une fois qu’il reçoit les résultats demandés par le serveur, les convertit au format d’origine pour le client. Il existe de nombreux types différents de cadres RPC, notamment XML-RPC et JSON-RPC.

Ces cadres d’appel de procédure à distance (RPC) sont légers, relativement simples à utiliser et offrent des avantages tels qu’un développement simplifié et une abstraction des communications réseau. Cependant, les environnements tels que les architectures de microservice et les systèmes avec des charges de données élevées nécessitent souvent un cadre de performance plus élevé, et gRPC a été développé pour répondre à ce besoin.

gRPC utilise un langage de définition d’interface (IDL) appelé Protocol Buffers (Protobuf) pour sérialiser les données structurées en binaire. Le binaire étant plus compact que le JSON ou le XML, il permet de transférer des charges utiles plus importantes à des vitesses plus rapides.

gRPC utilise également HTTP/2, ce qui permet un streaming bidirectionnel et fait de gRPC un excellent choix pour les API dans les environnements distribués (en particulier ceux qui nécessitent une communication en temps réel), les architectures de microservices, les applications de streaming et la connexion d’appareils de l’Internet des objets (IdO).

Rapidité : gRPC, par l’intermédiaire de Protobuf, sérialise et désérialise des données provenant de nombreux langages différents, notamment Java, Python, Ruby et autres, en une charge utile binaire à transmettre. Ce code est léger, de sorte que le temps de transmission et la latence dans l’échange de données sont réduits grâce aux API gRPC.

Génération de code : gRPC inclut un compilateur Protobuf appelé [protoc], qui offre une fonctionnalité de génération de code natif. Une fois la structure des données définie dans un fichier .proto, gRPC peut générer à la fois du code côté client et côté serveur.

Prise en charge HTTP/2 : s’appuyant sur le protocole de transport HTTP/2, gRPC prend en charge différents types de streaming. Par exemple, il prend en charge la diffusion bidirectionnelle, dans laquelle le client et le serveur peuvent envoyer indépendamment des messages dans un flux de lecture/écriture, en plus de la diffusion en continu côté client et côté serveur.

Intercepteurs : gRPC prend en charge les middlewares appelés intercepteurs, qui permettent des fonctionnalités améliorées. Des intercepteurs peuvent être installés pour mettre en œuvre la sécurité, l’authentification, l’analyse des indicateurs, etc.

Annulation et délais : gRPC prend en charge les annulations, également appelées délais d’expiration ou délais : une heure précise après laquelle l’appel sera annulé.

Nouveauté et écosystème : bien que gRPC comprenne des fonctionnalités supplémentaires telles que la génération de code, il s’agit d’une architecture relativement nouvelle, dont la première version n’a été publiée qu’en 2016. Cette nouveauté a laissé la documentation et la prise en charge limitées par rapport aux anciens styles d’architecture.

Courbe d’apprentissage abrupte : certains développeurs trouvent que la courbe d’apprentissage de gRPC est plus abrupte que celle de REST. Sa sérialisation des données binaires permet une communication efficace, mais n’est pas lisible par l’homme.

Absence de prise en charge des navigateurs : les navigateurs web ne prenant pas en charge le protocole gRPC en mode natif, il n’est pas possible d’appeler directement un service gRPC depuis une application basée sur un navigateur. Un moyen de contourner ce problème est d’utiliser un proxy tel que gRPC-Web. gRPC-Web agit essentiellement comme une couche de traduction entre le protocole HTTP et gRPC d’un navigateur.

REST et gRPC ont de nombreux éléments en commun et sont tous deux utilisés pour construire des systèmes évolutifs. Voici quelques similitudes :

Architecture client/serveur : gRPC et REST sont tous deux des architectures client/serveur avec un format demande/réponse qui permet à un client et à un serveur de communiquer et d’échanger des données. Dans cette architecture, un client envoie une requête et le serveur répond en renvoyant les données demandées ou en effectuant une action demandée.

Indépendant de la plateforme : gRPC et REST permettent aux services construits sur différentes plateformes de réseau avec différents systèmes d’exploitation de communiquer.

Sans état : REST et gRPC sont considérés comme sans état, ce qui signifie que chaque demande inclut toutes les informations nécessaires pour la compléter. Le serveur n’a pas besoin de magasin des informations sur les demandes précédentes.

Support linguistique : les deux styles architecturaux sont indépendants de la langue, ce qui signifie que ces API peuvent être utilisées par des applications écrites dans différents langages de programmation. Cette qualité les rend portables dans tous les environnements de programmation.

Utilisation du HTTP : REST et gRPC s’appuient tous deux sur une communication basée sur HTTP. Cependant, gRPC utilise HTTP/2, tandis que REST s’appuie sur HTTP/1.1. En outre, gRPC fait abstraction du protocole de communication HTTP/2 sous-jacent, alors que la communication HTTP est moins abstraite dans REST.

Les principales différences entre REST et gRPC peuvent aider les développeurs à décider quelle est la meilleure solution pour l’API qu’ils sont en train de créer. Ces différences incluent :

Format des données : les API REST utilisent principalement des formats textuels tels que JSON et XML. gRPC utilise Protobuf pour coder les données au format binaire.

Modèle de communication : REST ne prend en charge que la communication unaire, c’est-à-dire une demande suivie d’une réponse. gRPC en supporte d’autres, notamment le streaming bidirectionnel (le client et le serveur échangent indépendamment), le streaming serveur (une seule requête déclenche plusieurs réponses) et le streaming client (plusieurs requêtes aboutissent à une seule réponse).

Modèle de conception : gRPC a une conception orientée service, dans laquelle les opérations de serveur appelables sont définies comme des services ou des fonctions. Dans REST, la conception est orientée ressources, dans laquelle les méthodes HTTP sont utilisées pour accéder aux ressources du serveur via des points de terminaison définis par des URL.

Couplage : le client et le serveur de gRPC sont étroitement liés, ce qui signifie que le client et le serveur doivent avoir accès au même fichier prototype du middleware. Tout changement dans l’un implique un changement dans l’autre. REST est couplé de manière souple. Cette indépendance signifie que les changements dans un composant n’affectent pas l’autre.

Génération de code : gRPC offre une génération de code intégrée, ce qui n’est pas le cas de REST, bien que des modules d’extension soient disponibles.

Mise en œuvre : REST ne nécessite aucun logiciel spécifique et prend en charge les navigateurs. gRPC nécessite un logiciel spécifique côté serveur et côté client.

REST est un choix populaire de conception d’API pour une raison bien précise : sa simplicité, sa large compatibilité et sa polyvalence en font un excellent choix pour de nombreuses applications. Pour les API publiques, REST est souvent le choix le plus judicieux, car il est plus largement utilisé et souvent plus facile à comprendre. De nombreux développeurs sont plus familiers avec REST et peuvent disposer d’une infrastructure importante spécifiquement pour REST, notamment des serveurs, des outils d’API management, des outils de développement et divers outils de test.

REST prend également en charge la mise en cache intégrée ou la possibilité de magasin les données fréquemment consultées, que ce soit localement ou via un proxy. La mise en cache peut considérablement améliorer la vitesse et l’efficacité, même si elle doit également inclure diverses informations de validation, d’authentification et d’expiration.

REST est également généralement préféré pour les services web et les API web, en raison de sa prise en charge de HTTP/1.1 et de sa prise en charge universelle des navigateurs. Il est généralement préférable de recourir à gRPC pour des communications de données plus simples. Son couplage lâche et sa complexité réduite peuvent améliorer l’évolutivité de l’architecture du système et contribuer à rendre un environnement plus flexible au fil du temps. Cependant, cette adaptabilité a un coût en termes de performances. 

gRPC est une architecture relativement récente, les développeurs adoptant de plus en plus sa vitesse, son efficacité et ses outils intégrés. Il est souvent utilisé pour les applications de flux en temps réel et les API complexes qui nécessitent une adresse performance élevée et le traitement de charges de données importantes dans les systèmes distribués. Bien que plus complexe que REST, l’utilisation de HTTP/2 et Protobuf donne à gRPC une meilleure évolutivité en termes de performance. 

gRPC est bien adapté aux architectures de microservices, car sa capacité à diffuser des données bidirectionnelles en temps réel permet aux différents services d’une application d’envoyer et de recevoir simultanément et indépendamment. Il bénéficie également d’un soutien dans les applications mobiles en raison de sa transmission de données rapide et compacte et parce que les applications mobiles sont moins susceptibles de s’appuyer sur un navigateur.

gRPC est également idéal pour connecter des éléments IdO aux API back-end, car ses charges utiles compactes, sa faible latence et son efficacité de performance s’adaptent bien à la technologie à faible consommation.