Programmation · web · API

gRPC vs REST

Quand vous concevez la communication entre deux programmes sur un réseau, la bifurcation moderne est REST vs gRPC. Les deux exposent des fonctionnalités via HTTP, mais font des paris opposés : REST privilégie la simplicité lisible et universelle ; gRPC l’efficacité rapide, typée, binaire. Ce guide les compare honnêtement sur le format, la performance, le streaming, le support navigateur et l’outillage — et quand choisir chacun. (Nouveau sur les API ? Commencez par qu’est-ce qu’une API.)

La différence fondamentale

• REST — un style d’architecture sur HTTP : ressources à des URL, verbes HTTP (GET/POST/PUT/DELETE), en général du JSON. Lisible, sans état, universel.
• gRPC — un framework d’appels de procédure distante : vous appelez des méthodes (comme des fonctions locales) définies dans un contrat .proto, en échangeant des Protocol Buffers binaires sur HTTP/2.

REST est orienté ressources (« récupère cette chose ») ; gRPC est orienté action (« appelle cette méthode »). REST est du texte ; gRPC est binaire et fortement typé.

Performance et transport

Les Protocol Buffers de gRPC sont du binaire compact, envoyé sur des connexions HTTP/2 multiplexées — charges plus petites, moins de parsing, plusieurs appels sur une connexion. Le JSON de REST sur HTTP/1.1 est plus lourd et verbeux, quoique très optimisé et cachable. Pour le trafic entre services à fort volume, l’efficacité de gRPC est réelle ; pour une API publique typique, REST suffit souvent et profite du cache HTTP gratuit.

Streaming, contrats et codegen

gRPC supporte nativement le streaming bidirectionnel (client, serveur, et les deux sens), idéal pour le temps réel et le fort débit. Son fichier .proto est un contrat strict à partir duquel clients et serveurs sont générés dans de nombreux langages — parfait pour les back-ends polyglottes et pour détecter les incompatibilités à la compilation. REST n’a pas de contrat intégré (OpenAPI/Swagger est ajouté) et le streaming est limité (SSE/WebSockets ajoutés), mais cette souplesse est aussi ce qui le rend facile à démarrer.

Support navigateur et ubiquité

C’est le terrain de REST. N’importe quel navigateur appelle une API REST via fetch ; chaque langage et outil la comprend ; on la débogue avec curl et on lit le JSON. Les navigateurs ne parlent pas gRPC brut — il faut gRPC-Web plus un proxy (ex. Envoy), ce qui ajoute des pièces mobiles. Si vos front-ends web sont les consommateurs principaux, REST (ou GraphQL) est plus simple.

Comment choisir

• Prenez REST pour les API publiques, les clients navigateur, le CRUD simple, et quand lisibilité, ubiquité et cache HTTP comptent.
• Prenez gRPC pour les appels internes entre services où performance, faible latence, streaming et contrat typé strict comptent (microservices, temps réel, polyglotte).
• Les deux — REST/GraphQL au bord pour les clients, gRPC entre services internes : une architecture très répandue.

Questions fréquentes

Quelle est la différence entre gRPC et REST ?

REST est un style d’architecture pour API web bâti sur HTTP, échangeant en général du JSON lisible via des URL de ressources. gRPC est un framework RPC haute performance qui tourne sur HTTP/2 et échange des Protocol Buffers binaires, définis par un contrat .proto strict. En bref : REST est orienté ressources, textuel et universel ; gRPC est orienté action (méthode), binaire, typé et rapide. Les deux résolvent le même problème — des programmes qui communiquent sur un réseau — avec des compromis différents.

gRPC est-il plus rapide que REST ?

En général oui pour le trafic entre services. gRPC envoie des Protocol Buffers binaires compacts sur des connexions HTTP/2 multiplexées : charges utiles plus petites, moins de surcharge que JSON sur HTTP/1.1, et streaming bidirectionnel. L’écart compte surtout pour les microservices internes à fort volume ; pour une API publique peu chargée, REST + cache HTTP est souvent largement suffisant.

Peut-on utiliser gRPC dans un navigateur ?

Pas directement. Les navigateurs ne parlent pas gRPC brut car ils n’exposent pas le contrôle HTTP/2 bas niveau dont gRPC a besoin. On utilise gRPC-Web avec un proxy (ex. Envoy) comme pont, ce qui ajoute de la complexité et limite certaines fonctions (comme le streaming client). REST, lui, fonctionne nativement depuis n’importe quel navigateur via fetch. Si votre API est surtout consommée par des front-ends web, REST (ou GraphQL) est plus simple.

Quand utiliser gRPC plutôt que REST ?

Choisissez gRPC pour la communication interne entre services où la performance, la faible latence, le streaming et un contrat typé strict comptent — microservices, données temps réel, back-ends polyglottes. Choisissez REST pour les API publiques, les clients navigateur, le CRUD simple de ressources, et quand la lisibilité, l’ubiquité et le cache HTTP gratuit priment. Beaucoup de systèmes utilisent les deux : REST/GraphQL au bord pour les clients, gRPC entre services internes.

En résumé

REST et gRPC ne sont pas des rivaux mais des outils pour des tâches différentes. REST gagne sur l’universalité, le support navigateur, la lisibilité et le cache — le bon défaut pour les API publiques et web. gRPC gagne sur la vitesse, le streaming et les contrats typés — le bon défaut pour les microservices internes haute performance. Choisissez selon vos appelants et votre trafic, et n’hésitez pas à utiliser les deux.