REST vs gRPC : choisir le bon style d'API pour votre application

Ce que sont REST et gRPC (en termes simples)

Quand on compare REST et gRPC, on compare en réalité deux façons différentes pour des logiciels de « se parler » sur un réseau.

REST : des API HTTP basées sur des ressources

REST est un style de conception d'API centré sur les ressources — les choses que votre application gère, comme des utilisateurs, des commandes ou des factures. Vous interagissez avec ces ressources via des requêtes HTTP familières :

• GET pour lire des données (par exemple, GET /users/123)
• POST pour créer quelque chose (par exemple, POST /orders)
• PUT/PATCH pour mettre à jour
• DELETE pour supprimer

Les réponses sont souvent en JSON, facile à inspecter et largement supporté. REST paraît naturel car il colle au fonctionnement du web — et parce qu'on peut le tester depuis un navigateur ou avec des outils simples.

gRPC : appeler des fonctions sur un autre service

gRPC est un framework pour les appel de procédures distantes (RPC). Plutôt que de penser en « ressources », on pense en méthodes à exécuter sur un autre service, comme CreateOrder ou GetUser.

Sous le capot, gRPC utilise typiquement :

• HTTP/2 pour des connexions efficaces
• Protocol Buffers (format binaire compact) pour les messages
• Un contrat fortement défini (un fichier .proto) qui permet de générer du code client et serveur

Le résultat donne souvent l'impression d'appeler une fonction locale — sauf qu'elle s'exécute ailleurs.

Ce que ce guide vous aide à décider

Ce guide vous aide à choisir selon des contraintes réelles : attentes de performance, types de clients (navigateur vs mobile vs services internes), besoins temps réel, workflow d'équipe et maintenance à long terme.

Il n'y a pas de réponse universelle. Beaucoup d'équipes utilisent REST pour les API publiques ou partenaires et gRPC pour la communication interne entre services — mais vos contraintes et objectifs doivent guider le choix.

Facteurs clés à considérer d'abord

Avant de comparer les fonctionnalités, clarifiez ce que vous optimisez. REST et gRPC peuvent fonctionner tous les deux, mais ils excellent sous des contraintes différentes.

1) Qui utilisera l'API ?

Commencez par les clients.

• Si votre API doit être appelée directement depuis des navigateurs (y compris des sites tiers) ou doit être facilement testable avec curl, REST est généralement le choix le plus sûr.
• Si la plupart des appelants sont des services internes que vous contrôlez (appels service-à-service dans un microservices), gRPC convient souvent mieux car il est conçu autour de contrats fortement typés et de clients générés.

2) Où cela s'exécutera : internet public ou réseau privé ?

Sur l'internet public, vous vous soucierez des proxies, des couches de cache et de la compatibilité avec des outils variés. REST sur HTTP est largement supporté et traverse souvent mieux les réseaux d'entreprise.

Dans un réseau privé (ou entre services sur la même plateforme), vous pouvez tirer parti du protocole plus strict de gRPC et de communications plus structurées — surtout quand vous contrôlez les deux extrémités.

3) Quels sont vos patterns de données et d'appels ?

Demandez-vous à quoi ressemble le « trafic normal » :

• CRUD simple avec des requêtes occasionnelles : REST est simple à raisonner.
• Appels fréquents et petits (interactions bavardes) ou trafic interne à haut débit : gRPC peut réduire la surcharge et maintenir l'alignement client/serveur.
• Gros payloads : les deux peuvent convenir, mais soyez explicite sur les limites, la pagination/découpage et les timeouts.

4) Avez-vous besoin d'un comportement temps réel ?

Si vous avez besoin de streaming (événements, mises à jour de progression, flux continus), prenez cela en compte tôt. On peut construire des patterns temps réel autour de REST, mais le modèle de streaming de gRPC est souvent plus naturel lorsque les deux côtés le supportent.

5) Contraintes et standards de l'équipe

Choisissez ce que votre équipe peut livrer et exploiter en toute confiance. Considérez les standards d'API existants, les habitudes de débogage, le rythme de release et la rapidité d'onboarding des nouveaux développeurs. Un protocole « idéal » qui ralentit la livraison ou augmente le risque opérationnel n'est pas le meilleur choix pour votre projet.

Principes du protocole : HTTP, contrats et comment fonctionnent les appels

Au niveau du protocole, REST et gRPC reviennent tous deux à « un client appelle un serveur », mais ils décrivent cet appel différemment : REST met l'accent sur les ressources HTTP et les codes de statut, tandis que gRPC met l'accent sur des méthodes distantes et un schéma strict.

REST : verbes HTTP, codes de statut et en-têtes

Les API REST tournent typiquement sur HTTP/1.1, et de plus en plus sur HTTP/2. La « forme » d'un appel REST est définie par :

• chemins d'URL comme ressources (par exemple, /users/123)
• verbes HTTP qui décrivent l'intention : GET, POST, PUT, PATCH, DELETE
• codes de statut qui communiquent les résultats : 200, 201, 400, 401, 404, 500, etc.
• en-têtes pour les métadonnées (tokens d'auth, cache, type de contenu) et la négociation de contenu (Accept, Content-Type)

Le pattern typique est requête/réponse : le client envoie une requête HTTP et le serveur renvoie une réponse avec un code, des en-têtes et un corps (souvent JSON).

gRPC : HTTP/2, méthodes, metadata et deadlines

gRPC utilise toujours HTTP/2, mais n'expose pas les « ressources + verbes » comme interface principale. À la place, vous définissez des services avec des méthodes (comme CreateUser ou GetUser) et vous les appelez comme des RPC.

En plus de la charge utile, gRPC supporte :

• Metadata (paires clé/valeur similaires aux en-têtes)
• Deadlines/timeouts en concept de première classe, permettant aux clients de dire « cet appel doit finir en 200ms » et aux serveurs d'arrêter le travail si le délai est dépassé

Comment le modèle d'appel diffère : request/response vs RPC

REST demande : « Sur quelle ressource opérez-vous, et quel verbe HTTP convient ? »

gRPC demande : « Quelle méthode appelez-vous, et quel message typé attend-elle/en retourne-t-elle ? »

Cette différence impacte le nommage, la gestion des erreurs (codes HTTP vs statuts gRPC) et la génération de clients.

Ce que signifie « contrat » dans chaque approche

• Contrat REST : souvent documenté avec OpenAPI plus des conventions (endpoints, champs, codes). C'est flexible, mais la cohérence dépend de la discipline.
• Contrat gRPC : un schéma .proto est le contrat. Il définit services, méthodes et messages typés, permettant la génération de code fiable et des règles d'évolution plus claires.

Performance et efficacité : ce que vous gagnez et ce que vous cédez

La performance est l'un des motifs les plus cités pour adopter gRPC — mais le gain n'est pas automatique. La vraie question est quel type de « performance » vous recherchez : latence par appel plus basse, meilleur débit sous charge, coût bande passante réduit ou efficacité serveur.

REST : JSON lisible, mais plus d'overhead

La plupart des APIs REST utilisent JSON sur HTTP/1.1. JSON est facile à inspecter, logger et déboguer — une forme d'efficacité pratique pour les équipes.

Le compromis est que JSON est verbeux et coûte plus de CPU pour parser et générer, surtout avec des payloads lourds ou des appels fréquents. HTTP/1.1 peut aussi ajouter des frais de connexion et de requête quand les clients font beaucoup de requêtes parallèles.

REST peut aussi être un gain de performance dans les architectures orientées lecture : le caching HTTP (via ETag, Cache-Control) peut réduire fortement les requêtes répétées — notamment avec des CDN.

gRPC : messages plus petits et meilleur usage des connexions

gRPC utilise typiquement Protocol Buffers (binaire) sur HTTP/2. Cela signifie souvent :

• Payloads plus compacts que JSON (moins de bande passante)
• Sérialisation/désérialisation plus rapide (moins de CPU)
• Multiplexage HTTP/2 (beaucoup d'appels sur une même connexion)

Ces bénéfices apparaissent surtout pour des appels service-à-service avec un fort volume de requêtes, ou quand vous transférez beaucoup de données à l'intérieur d'un système de microservices.

Latence vs débit : à quoi s'attendre

Sur un système calme, REST et gRPC peuvent sembler aussi rapides. Les différences deviennent plus visibles avec l'augmentation de la concurrence.

• Latence (temps par appel) : gRPC améliore souvent la latence en queue (tail latency) car il évite des overheads de connexion répétée et utilise des payloads compacts.
• Débit (appels par seconde) : gRPC tend à mieux monter en charge sur la même infrastructure sous forte charge.

Quand c'est important (et quand ça ne l'est pas)

Les différences de performance importent surtout quand vous avez des appels internes à haute fréquence, de gros payloads, des contraintes de bande passante mobile strictes, ou des SLOs serrés.

Elles importent moins lorsque votre API est dominée par le temps de base de données, des appels tiers ou un usage à échelle humaine (tableaux d'administration, applications CRUD typiques). Dans ces cas, la clarté, la cacheabilité et la compatibilité client peuvent primer sur l'efficacité brute du protocole.

Streaming et communication temps réel

Les fonctionnalités temps réel — tableaux de bord en direct, chat, collaboration, télémétrie, notifications — dépendent de la façon dont votre API gère la communication « continue », pas seulement des requêtes ponctuelles.

REST : request/response, plus des patterns asynchrones courants

REST est fondamentalement request/response : le client demande, le serveur répond, la connexion se termine. On peut construire du temps réel autour de REST, mais cela repose en général sur des patterns extérieurs :

• Polling : le client demande « y a-t-il du nouveau ? » toutes les N secondes. Simple, mais gaspille bande passante et batterie quand les mises à jour sont rares, et ajoute de la latence quand N est grand.
• Long polling : le serveur garde la requête ouverte jusqu'à une mise à jour (ou un timeout), puis le client se reconnecte. Moins gaspilleur que le polling, mais toujours reconnect-heavy.
• Webhooks : le serveur appelle votre endpoint quand quelque chose change. Excellent pour des intégrations partenaires, mais nécessite des endpoints publics, une vérification de signature, la gestion des retries et l'idempotence.

(Pour le temps réel côté navigateur, les équipes ajoutent souvent WebSockets ou SSE en complément de REST ; c'est un canal séparé avec son propre modèle opérationnel.)

gRPC : le streaming est une fonctionnalité de première classe

gRPC prend en charge plusieurs types d'appels sur HTTP/2, et le streaming est intégré au modèle :

• Unary : une requête, une réponse (similaire à REST).
• Server streaming : une requête, plusieurs réponses (le serveur pousse des mises à jour).
• Client streaming : plusieurs requêtes, une réponse (le client envoie un flux de données).
• Bidirectional streaming : les deux côtés envoient des messages indépendamment (conversation temps réel).

Cela fait de gRPC un bon choix quand vous voulez un flux soutenu de messages à faible latence sans recréer constamment de nouvelles requêtes HTTP.

Cas d'usage qui profitent du streaming

Le streaming brille pour :

• Métriques et logs en direct (appareils ou services rapportant continuellement)
• Chat, présence, curseurs de collaboration (mises à jour bidirectionnelles)
• Données de marché / flux en direct (server streaming)
• Médias ou upload de gros fichiers (client streaming)
• Notifications en fan-out à l'intérieur des microservices (flux d'événements service-à-service)

Considérations opérationnelles pour les connexions longues

Les streams longs changent la manière d'exploiter les systèmes :

• Load balancing : il faut des stratégies qui fonctionnent avec des connexions HTTP/2 longues et sticky.
• Timeouts/keepalives : les paramétrer pour éviter les déconnexions silencieuses et détecter les pairs morts.
• Backpressure : le streaming peut submerger des consommateurs lents ; prévoyez du flow control et des limites de messages.
• Usage des ressources : chaque stream ouvert consomme mémoire et concurrence ; fixez des quotas et surveillez la saturation.

Si le « temps réel » est au cœur de votre produit, le modèle de streaming de gRPC peut réduire la complexité par rapport à empiler polling/webhooks (ou WebSockets) au-dessus de REST.

Expérience développeur, outils et maintenabilité

Le choix entre REST et gRPC ne tient pas qu'à la vitesse : votre équipe vivra avec l'API quotidiennement. Outils, onboarding et capacité à faire évoluer l'interface en sécurité comptent souvent plus que le débit brut.

REST : outils accessibles et débogage aisé

REST est familier car il repose sur du HTTP simple et parle souvent JSON. La boîte à outils est universelle : outils dev du navigateur, curl, Postman/Insomnia, proxies et logs lisibles sans visionneuse spéciale.

Quand quelque chose casse, le débogage est souvent simple : rejouer une requête depuis le terminal, inspecter les en-têtes, comparer les réponses. Cette commodité explique en grande partie pourquoi REST est courant pour les API publiques et pour les équipes qui font beaucoup de tests ad hoc.

gRPC : contrats forts, clients générés, moins de surprises

gRPC utilise typiquement Protocol Buffers et la génération de code. Au lieu d'assembler manuellement des requêtes, les développeurs appellent des méthodes typées dans leur langage.

Le bénéfice est la sûreté des types et un contrat clair : champs, enums et formes de messages sont explicites. Cela réduit les bugs « stringly-typed » et les incompatibilités client/serveur — particulièrement dans la communication microservices.

Courbe d'apprentissage et onboarding

REST est plus rapide à prendre en main : « envoyer une requête HTTP à cette URL ». gRPC demande aux nouveaux membres de comprendre les fichiers .proto, la génération de code et parfois des workflows de débogage différents. Les équipes habituées au typage fort et aux schémas partagés s'adaptent plus vite.

Gérer les évolutions d'API en pratique

Avec REST/JSON, la gestion des changements repose souvent sur des conventions (ajouter des champs, déprécier des endpoints, versions dans l'URL). Avec gRPC/Protobuf, les règles de compatibilité sont plus formelles : ajouter des champs est généralement sûr, renommer/supprimer ou changer les types peut casser des consommateurs.

Dans les deux approches, la maintenabilité s'améliore quand vous traitez l'API comme un produit : documentez, automatisez des tests de contrat et publiez une politique de dépréciation claire.

Compatibilité client : web, mobile et tiers

Le choix entre REST et gRPC revient souvent à qui appellera votre API — et depuis quels environnements.

REST : le chemin le plus simple pour « n'importe quel client »

REST sur HTTP + JSON est largement supporté : navigateurs, apps mobiles, outils en ligne de commande, plateformes low-code et systèmes partenaires. Si vous créez une API publique ou attendez des intégrations tierces, REST minimise la friction car les consommateurs peuvent commencer avec des requêtes simples puis adopter des SDK.

REST s'intègre aussi naturellement aux contraintes web : les navigateurs gèrent bien HTTP, les caches et proxies le comprennent, et le débogage est simple avec des outils courants.

gRPC : excellent pour des clients contrôlés, plus compliqué pour des écosystèmes ouverts

gRPC brille quand vous contrôlez les deux extrémités (vos services, vos applications internes). Il utilise HTTP/2 et Protocol Buffers, ce qui peut apporter un gros gain en performance et cohérence — mais tous les environnements ne peuvent pas l'adopter facilement.

Par exemple, les navigateurs ne supportent pas les appels gRPC « natifs ». On peut utiliser gRPC-Web, mais cela ajoute des composants et des contraintes (proxies, types de contenu spécifiques, outillage différent). Exiger gRPC pour des tiers peut être une barrière supérieure à fournir un endpoint REST.

Si vous avez besoin des deux : utilisez une gateway

Un pattern courant est de garder gRPC en interne pour les appels service-à-service et d'exposer REST en externe via une gateway ou une couche de traduction. Cela permet aux partenaires d'utiliser HTTP/JSON familier tandis que vos systèmes internes gardent un contrat typé.

SDKs et support client : comment y penser

• Avec REST, les SDKs sont optionnels mais utiles ; beaucoup de consommateurs appelleront votre API sans SDK.
• Avec gRPC, les bibliothèques client générées font partie du modèle. C'est un atout (sécurité des types, moins de bugs manuels) tant que vos consommateurs peuvent générer et mettre à jour ces clients.

Si votre audience inclut des tiers inconnus, REST est généralement le choix le plus sûr. Si l'audience est majoritairement vos propres services, gRPC est souvent plus adapté.

Sécurité, observabilité et exploitation

La sécurité et l'opérabilité sont souvent là où « joli en démo » devient « dur en production ». REST et gRPC peuvent être tous deux sécurisés et observables, mais ils correspondent à des patterns d'infrastructure différents.

Sécurité : transport et authentification

REST s'appuie généralement sur HTTPS (TLS). L'authentification se transporte souvent via des en-têtes HTTP :

• OAuth 2.0 / OpenID Connect (Bearer tokens) pour les apps orientées utilisateur
• Clés API pour des intégrations partenaires plus simples (souvent combinées à du rate limiting)
• Signature des requêtes optionnelle (pour une plus haute assurance)

Comme REST s'appuie sur les sémantiques HTTP connues, il s'intègre facilement aux WAF, reverse proxies et API gateways qui comprennent déjà chemins et en-têtes.

gRPC utilise aussi TLS, mais l'authentification passe souvent via metadata (paires clé/valeur similaires aux en-têtes). Il est courant d'ajouter :

• Identité service-à-service (mTLS, SPIFFE/SPIRE, ou certificats émis par un mesh)
• Tokens dans les metadata (par exemple authorization: Bearer …)
• Deadlines par appel pour limiter la durée d'exécution d'une requête (avantage pour la fiabilité et la sécurité)

Observabilité : logs, métriques et tracing

Pour REST, la plupart des plateformes fournissent des access logs, codes de statut et timings de requêtes. Vous pouvez faire beaucoup avec des logs structurés et des métriques standards (latence p50/p95, taux d'erreur, débit).

Pour gRPC, l'observabilité est excellente une fois instrumentée, mais moins « automatique » dans certains stacks car on ne traite pas des URLs simples. Priorisez :

• Nommage de méthodes cohérent (service/method) dans les logs
• Métriques pour statuts gRPC, latence, retries et tailles de message
• Tracing distribué (OpenTelemetry) pour suivre une requête utilisateur à travers plusieurs services

Exploitation : gateways, ingress et service meshes

Les setups REST courants placent un ingress ou API gateway en bordure, gérant TLS, auth, rate limiting et routage.

gRPC fonctionne aussi bien derrière un ingress, mais vous aurez souvent besoin de composants qui supportent HTTP/2 et les fonctionnalités gRPC. Dans les environnements microservices, un service mesh peut simplifier mTLS, retries, timeouts et télémétrie pour gRPC — surtout quand beaucoup de services communiquent entre eux.

Conclusion opérationnelle : REST s'intègre souvent plus naturellement aux outils web standards, tandis que gRPC brille quand vous standardisez sur deadlines, identité de service et télémétrie uniforme pour les appels internes.

Scénarios courants et choix recommandés

La plupart des équipes ne choisissent pas REST ou gRPC en théorie : elles choisissent ce qui convient à leurs utilisateurs, clients et modèle de trafic. Ces scénarios rendent souvent les compromis plus clairs.

Quand REST est le choix pragmatique par défaut

REST est souvent le « choix sûr » quand votre API doit être largement consommable et facile à explorer.

Utilisez REST lorsque vous construisez :

• API publiques ou partenaires où des tiers inconnus s'intègrent
• APIs CRUD (utilisateurs, commandes, produits) qui se mappent bien à GET/POST/PUT/DELETE
• Endpoints orientés navigateur où JSON sur HTTP est la norme
• Produits en phase initiale où vous voulez le moins de friction client et un débogage simple (curl, Postman, logs)

REST brille souvent aux frontières de votre système : lisible, cache-friendly et compatible avec gateways, documentation et infra commune.

Quand gRPC est un gain évident

gRPC est généralement mieux adapté pour la communication service-à-service où l'efficacité et les contrats forts comptent.

Choisissez gRPC si vous avez :

• Microservices avec de nombreux appels internes par requête
• Flux élevé ou sensibles à la latence (recommandations, tarification, détection de fraude)
• Besoins de streaming (server, client ou bidirectionnel)
• Contrats stricts que vous voulez partager entre équipes et langages (via Protocol Buffers)

Dans ces cas, l'encodage binaire et HTTP/2 de gRPC réduisent souvent l'overhead et rendent la performance plus prédictible quand le trafic interne augmente.

Quand mixer les deux est sensé

Un pattern pratique courant :

• REST en bordure pour web/mobile/clients tiers
• gRPC en interne pour microservices et backends à haut débit

Cela limite les contraintes de compatibilité de gRPC à votre environnement contrôlé, tout en offrant des bénéfices de contrat typé et d'efficacité en interne.

Anti-patterns à éviter

Quelques choix provoquent souvent des douleurs :

• "Over-RPC REST" : forcer tout dans des endpoints comme /doThing et perdre la clarté d'un design orienté ressources.
• Adopter gRPC trop tôt : le choisir parce que ça paraît plus rapide, alors que le vrai problème est des frontières floues, des services bavards ou un manque de caching.
• Utiliser gRPC pour l'accès large à des tiers sans plan pour le support navigateur, les bibliothèques clients et l'onboarding.

Si vous hésitez, par défaut utilisez REST pour les APIs externes et adoptez gRPC là où vous pouvez prouver son bénéfice : à l'intérieur de la plateforme, sur les chemins chauds, ou lorsque le streaming et les contrats stricts sont vraiment utiles.

Checklist pratique pour votre prochain projet

Choisir entre REST et gRPC devient plus simple quand vous partez des consommateurs et de ce qu'ils doivent accomplir — pas des tendances.

1) Partir des consommateurs et des cas d'usage

Demandez-vous :

• Qui sont les consommateurs ? Navigateurs, mobiles, services internes, partenaires externes.
• Qu'est-ce que « facile » signifie pour eux ? Requêtes curlables, clients générés, docs stables, SDK.
• Comment l'API évoluera-t-elle ? Changements fréquents, compatibilité stricte, équipes multiples releaseant indépendamment.

2) Checklist rapide (choisissez ce qui importe le plus)

• Besoins de performance : taille de payload et latence critiques (haut QPS, gros objets, SLAs serrés) ?
• Streaming : besoin de server streaming, client streaming ou updates bidirectionnelles ?
• Compatibilité client : doit-il fonctionner directement depuis les navigateurs sans gateways ? Des tiers doivent-ils y accéder facilement ?
• Outils & workflows : vos équipes préfèrent-elles des contrats typés et clients générés, ou du JSON flexible et de l'intégration manuelle ?
• Exploitation : votre plateforme peut-elle faire tourner HTTP/2 de bout en bout et gérer load balancing, retries, timeouts et règles de versioning ?
• Observabilité : tracing, logging et reporting d'erreurs seront-ils simples avec vos outils existants ?

3) Plan pilote : implémentez un endpoint de référence des deux façons

Choisissez un endpoint représentatif (pas un « Hello World ») et construisez-le en :

• REST (JSON sur HTTP)
• gRPC (protobuf sur HTTP/2)

Mesurez :

• Latence (p50/p95), taille du payload et CPU serveur
• Effort client (lignes de glue code, temps d'intégration)
• Friction opérationnelle (débogage, proxies/gateways, monitoring)

Si vous souhaitez accélérer ce pilote, un workflow de scaffolding peut aider : par exemple, sur Koder.ai vous pouvez générer rapidement une petite application et backend depuis un prompt, puis tester à la fois une surface REST et un service gRPC en interne. Koder.ai produit des projets réels (React pour le web, backends Go avec PostgreSQL, Flutter pour mobile), ce qui permet de valider non seulement des benchmarks, mais aussi l'expérience développeur — documentation, intégration client et déploiement. Des fonctionnalités comme le mode planning, les snapshots et le rollback sont utiles quand vous itérez sur la forme de l'API.

4) Documentez — et revoyez

Documentez la décision, les hypothèses (clients, trafic, streaming) et les métriques utilisées. Réévaluez lorsque les exigences changent (nouveaux consommateurs externes, montée en charge, besoins temps réel).

FAQ : réponses rapides aux questions fréquentes

“gRPC est-il plus rapide que REST ?” — ce qui influence les résultats

Souvent oui — surtout pour les appels service-à-service — mais pas automatiquement.

gRPC est efficace parce qu'il utilise HTTP/2 (multiplexage) et un format binaire compact (Protobuf). Cela réduit souvent le CPU et la bande passante comparé à JSON-over-HTTP.

La vitesse réelle dépend de :

• Taille et forme des payloads : de gros champs JSON répétitifs sont souvent plus lents que Protobuf.
• Conditions réseau : latence et établissement de connexion comptent autant que le débit pur.
• Implémentation serveur/client : overhead des frameworks, middlewares et logging peuvent dominer.
• Caching et proxies : REST bénéficie plus naturellement des patterns de cache HTTP.

Si la performance est un objectif clé, faites des benchmarks sur vos endpoints avec des données réalistes.

“Puis-je utiliser gRPC depuis les navigateurs ?” — possibilités et limitations

Les navigateurs ne peuvent pas utiliser le gRPC « natif » car ils n'exposent pas certaines fonctionnalités HTTP/2 basses requises par gRPC.

Options :

• gRPC-Web : fonctionne en navigateur via un proxy compatible, mais a des limitations par rapport au gRPC natif.
• Gateway REST/JSON : exposez un endpoint REST pour les clients web tout en gardant gRPC en interne.

Si vous ciblez des clients tiers ou majoritairement web, REST est habituellement la voie la plus simple.

“Dois-je utiliser Protobuf ?” — quand c'est utile

gRPC est conçu autour de Protobuf, la génération de code et le typage strict. Vous pouvez envoyer d'autres formats, mais vous perdrez beaucoup d'avantages.

Protobuf aide quand vous voulez des contrats clairs, des payloads plus petits et un code client/serveur cohérent.

“Comment versionner les APIs ?” — règles simples pour les deux

Pour REST, approches communes : /v1/ dans le chemin ou version via en-têtes ; gardez les changements backward-compatible autant que possible.

Pour gRPC, préférez faire évoluer les messages en toute sécurité : ajoutez des champs, évitez de renommer, et ne réutilisez pas des numéros de champ supprimés. Pour des changements cassants, publiez un nouveau service ou package (nouvelle version majeure).