Lorsque nous cliquons sur « Enregistrer », « Envoyer » ou « Valider », tout paraît presque instantané. La page réagit, une confirmation apparaît et nous passons à autre chose.
Pourtant, en coulisses, une véritable conversation vient d’avoir lieu. L’interface a formulé une demande, un serveur l’a comprise, une base de données a peut-être été interrogée, puis une réponse est revenue jusqu’à l’écran. Pour organiser ces échanges, les développeurs utilisent des API et différents protocoles de communication : REST, gRPC, WebSocket, HTTP/3, QUIC ou encore UDP.
Ces termes sont souvent présentés comme des technologies concurrentes. En réalité, ils ne jouent pas tous le même rôle. Certains décrivent la manière de formuler une demande, d’autres la façon de la transporter. Les comprendre permet surtout d’éviter une erreur fréquente : choisir une technologie parce qu’elle semble moderne, alors qu’elle ne répond pas au problème rencontré.
Une API n’est pas le tuyau qui transporte les données
Commençons par l’API. On peut l’imaginer comme le comptoir d’accueil d’une entreprise. Elle indique ce qu’il est possible de demander, sous quelle forme et avec quelles autorisations.
Une application peut ainsi demander :
- la liste des clients ;
- la création d’une commande ;
- l’état d’une livraison ;
- la modification d’une adresse.
L’API constitue donc un contrat de communication. Elle définit les demandes acceptées et la forme des réponses. Mais elle ne dit pas, à elle seule, comment les informations voyagent sur le réseau.
C’est là qu’interviennent REST, gRPC, HTTP, QUIC ou WebSocket. Pour reprendre notre comparaison, l’API est le comptoir et son catalogue de services. Les protocoles organisent la conversation et acheminent les messages.
REST : la conversation que presque tout le monde comprend
REST est aujourd’hui la manière la plus répandue de concevoir une API web. Techniquement, ce n’est pas un protocole, mais un style d’architecture généralement utilisé avec HTTP.
Son fonctionnement est assez naturel. Une adresse représente une ressource et les méthodes HTTP expriment l’action souhaitée :
GETpour consulter ;POSTpour créer ;PUTouPATCHpour modifier ;DELETEpour supprimer.
Les données sont souvent échangées au format JSON, un texte structuré qu’un humain peut encore lire. C’est l’une des grandes forces de REST : un développeur peut ouvrir une requête, comprendre ce qui a été envoyé et identifier assez rapidement l’origine d’une erreur.
REST est également très bien pris en charge par les navigateurs, les applications mobiles, les outils d’intégration et la quasi-totalité des langages. Pour une application de gestion, un portail client ou une API destinée à des partenaires, c’est souvent le choix le plus raisonnable.
Cette simplicité possède toutefois un coût. Le JSON peut devenir volumineux. Certaines pages doivent enchaîner plusieurs appels. Et si le contrat est mal documenté, le frontend et le backend peuvent finir par ne plus attendre exactement les mêmes données.
Une API REST devient donc beaucoup plus robuste lorsqu’elle est versionnée, documentée avec un standard comme OpenAPI et accompagnée de règles claires sur les erreurs, les droits et les formats de données.
Les avantages de REST : simplicité, compatibilité universelle, lisibilité, facilité de test et bonne adaptation aux API publiques.
Ses limites : messages parfois plus lourds, multiplication possible des appels et contrats moins stricts lorsqu’ils sont insuffisamment documentés.
gRPC : quand deux services doivent se parler vite et précisément
gRPC adopte une autre philosophie. Au lieu de manipuler principalement des adresses et des documents JSON, on définit des opérations et des messages dans un contrat formel, généralement écrit avec Protocol Buffers.
À partir de ce contrat, les outils peuvent générer automatiquement une partie du code nécessaire côté client et côté serveur. Les deux interlocuteurs savent précisément quels champs sont attendus, lesquels sont obligatoires et quel type de réponse sera renvoyé.
Les messages sont binaires. Ils sont donc généralement plus compacts et plus rapides à traiter que du JSON. gRPC gère aussi très bien le streaming : le serveur peut envoyer une suite de réponses sans recréer une nouvelle conversation à chaque fois.
C’est particulièrement intéressant lorsqu’un système est composé de plusieurs services internes très sollicités. Par exemple, un service de tarification peut interroger plusieurs milliers de fois par minute un service de catalogue ou de disponibilité.
Mais gRPC n’est pas automatiquement « meilleur » que REST. Un message binaire est moins facile à lire à l’œil nu. L’utilisation directe depuis un navigateur demande souvent une couche adaptée, comme gRPC-Web ou un proxy compatible. L’exploitation et le débogage réclament également des outils spécifiques.
Dans une application encore organisée en monolithe modulaire, remplacer de simples appels internes par gRPC peut surtout ajouter de la complexité sans apporter de gain visible à l’utilisateur.
Les avantages de gRPC : performances, messages compacts, contrats fortement typés, génération de code et streaming efficace.
Ses limites : débogage moins immédiat, intégration web plus délicate et complexité rarement justifiée pour une application simple ou une API publique.
WebSocket : garder la ligne ouverte
Avec une API REST classique, le client pose une question et le serveur répond. Puis l’échange se termine. Pour connaître une évolution, le client doit poser une nouvelle question.
WebSocket permet au contraire de garder la connexion ouverte. Une fois le canal établi, le client et le serveur peuvent s’envoyer des messages dans les deux sens, à tout moment.
C’est utile pour une messagerie instantanée, une édition collaborative, le suivi en direct d’une opération ou l’apparition immédiate d’une notification. Le serveur n’a plus besoin d’attendre que le navigateur lui demande s’il y a du nouveau : il peut pousser directement l’information.
Cette fluidité a un revers. Il faut maintenir les connexions, gérer les coupures, reconnecter les utilisateurs, éviter les messages en double et répartir correctement les connexions lorsque plusieurs serveurs fonctionnent ensemble. Pour créer ou modifier une fiche client, une API REST reste généralement plus simple. WebSocket doit être réservé aux fonctions qui ont réellement besoin du temps réel.
UDP : envoyer rapidement, sans demander de reçu
UDP se situe plus bas dans la mécanique du réseau. Ce n’est pas une façon de construire une API métier, mais un protocole de transport.
Son principe est minimaliste : un paquet est envoyé sans établir une longue conversation au préalable et sans garantie intégrée qu’il arrivera, qu’il arrivera dans le bon ordre ou qu’il n’arrivera pas deux fois.
Cela peut sembler peu rassurant, mais cette légèreté est très utile lorsque la rapidité compte davantage que la récupération de chaque paquet. Dans un appel vidéo, par exemple, il vaut souvent mieux perdre une fraction de seconde de son que bloquer toute la conversation en attendant sa retransmission. UDP est aussi utilisé dans les jeux en ligne, certaines communications temps réel et les requêtes DNS.
Pour une API de facturation, de stock ou de paiement, utiliser directement UDP serait en revanche une mauvaise idée. Il faudrait reconstruire soi-même les mécanismes de fiabilité, de sécurité, d’ordre et de reprise.
QUIC : partir d’UDP pour reconstruire un transport moderne
QUIC utilise UDP comme fondation, mais il ne reprend pas son absence de garanties. Il ajoute les éléments nécessaires à une communication web fiable : gestion des connexions, retransmission des données perdues, contrôle de congestion, flux multiples et chiffrement intégré avec TLS 1.3.
L’un de ses principaux intérêts apparaît lorsque le réseau devient imparfait. Avec certaines communications basées sur TCP, la perte d’un paquet peut retarder d’autres échanges qui n’ont pourtant rien à voir. QUIC sépare mieux les flux : si l’un rencontre un problème, les autres peuvent continuer à avancer.
Il gère également mieux les changements de réseau. Un smartphone peut passer du Wi-Fi à la 5G sans devoir nécessairement reconstruire toute la connexion comme auparavant. Dans la vie réelle, où les utilisateurs se déplacent et où les réseaux sont rarement parfaits, cela peut améliorer la sensation de rapidité.
QUIC reste toutefois plus complexe à observer et à diagnostiquer que les protocoles historiques. Certains pare-feu, équipements réseau ou outils de supervision anciens le comprennent moins bien. Dans la plupart des projets, il est pris en charge par le navigateur, le serveur web, le CDN ou le proxy : l’application métier n’a pas à le réimplémenter.
HTTP/3 : le Web adopte QUIC
HTTP/3 est la version d’HTTP conçue pour fonctionner sur QUIC, alors que HTTP/1.1 et HTTP/2 utilisent généralement TCP.
La relation entre ces technologies peut se résumer ainsi :
API REST classique → HTTP/1.1 ou HTTP/2 → TCP → IP
API via HTTP/3 → HTTP/3 → QUIC → UDP → IP
gRPC classique → HTTP/2 → TCP → IPUne API REST peut donc parfaitement être transportée par HTTP/3. REST et HTTP/3 ne sont pas des concurrents : REST structure l’API, tandis qu’HTTP/3 contribue à transporter les requêtes.
Pour l’utilisateur, les bénéfices d’HTTP/3 se ressentent surtout sur les connexions mobiles, les réseaux avec de la latence ou ceux qui perdent régulièrement des paquets. Sur un réseau local stable, la différence peut être imperceptible.
Son principal avantage est qu’il peut souvent être activé au niveau de l’infrastructure sans réécrire l’application. Son inconvénient est qu’il ajoute une couche technique à surveiller et que ses gains ne sont pas identiques dans tous les contextes.
Des technologies complémentaires, pas une compétition
| Technologie | Rôle principal | Idéale pour | Principal avantage | Principal inconvénient |
|---|---|---|---|---|
| REST/JSON | Concevoir une API web | Applications métier, mobiles et API partenaires | Simple et universel | Échanges parfois plus volumineux |
| gRPC | Appeler des fonctions distantes | Communications internes à fort volume | Rapide et fortement typé | Moins naturel dans un navigateur |
| WebSocket | Maintenir un canal bidirectionnel | Chat, collaboration et notifications en direct | Véritable temps réel | Connexions plus complexes à exploiter |
| UDP | Transporter des paquets avec très peu de surcharge | Voix, vidéo, jeux et télémétrie | Très faible latence | Aucune garantie native de livraison |
| QUIC | Fournir un transport moderne sur UDP | Connexions web mobiles ou instables | Rapidité, sécurité et flux indépendants | Diagnostic et infrastructure plus exigeants |
| HTTP/3 | Transporter le Web sur QUIC | Sites et API accessibles sur Internet | Meilleure résistance aux réseaux imparfaits | Gain parfois faible sur un réseau stable |
Alors, que faut-il choisir pour une API ?
Pour la majorité des applications métier, le bon point de départ reste une API REST bien conçue, échangée en HTTPS et documentée avec précision. Elle est facile à intégrer, à tester et à faire évoluer. HTTP/2 ou HTTP/3 peuvent ensuite améliorer le transport sans modifier les principes de l’API.
gRPC mérite d’être envisagé lorsque plusieurs services indépendants communiquent très fréquemment, que les volumes deviennent importants et qu’un contrat strict apporte une vraie valeur. Pas simplement parce qu’il est réputé plus rapide.
WebSocket est pertinent lorsqu’une fonctionnalité perd son intérêt sans mise à jour instantanée. Il peut alors compléter REST : l’API classique gère les opérations métier, tandis que WebSocket transmet les événements en direct.
Quant à UDP et QUIC, ils appartiennent surtout à la couche de transport. Une application de gestion n’a généralement aucune raison de manipuler UDP directement. QUIC et HTTP/3 seront plus souvent activés et administrés par l’infrastructure qui expose l’application sur Internet.
La meilleure architecture est souvent celle que l’équipe peut encore comprendre
Dans la technologie, les nouveautés ont toujours quelque chose de séduisant. Un protocole plus rapide, un format plus compact ou une architecture plus distribuée donnent facilement l’impression de préparer l’avenir.
Mais chaque technologie ajoutée devient aussi une technologie à sécuriser, superviser, expliquer et maintenir. Une architecture n’est pas moderne parce qu’elle accumule les protocoles. Elle l’est lorsqu’elle répond efficacement aux besoins présents tout en laissant une porte ouverte aux évolutions futures.
Le bon choix n’est donc pas « REST ou gRPC pour toujours », ni « HTTP/3 à tout prix ». C’est souvent : REST tant que sa simplicité suffit, WebSocket là où le temps réel apporte une vraie valeur, gRPC lorsque les échanges internes l’exigent réellement, et HTTP/3 lorsque l’infrastructure et les usages réseau permettent d’en tirer profit.
Autrement dit, le meilleur protocole n’est pas le plus impressionnant sur un schéma d’architecture. C’est celui qui rend la communication fiable pour l’utilisateur et compréhensible pour l’équipe qui devra encore la faire fonctionner dans trois ans.
Lorsque nous cliquons sur « Enregistrer », « Envoyer » ou « Valider », tout paraît presque instantané. La page réagit, une confirmation apparaît et nous passons à autre chose.
Pourtant, en coulisses, une véritable conversation vient d’avoir lieu. L’interface a formulé une demande, un serveur l’a comprise, une base de données a peut-être été interrogée, puis une réponse est revenue jusqu’à l’écran. Pour organiser ces échanges, les développeurs utilisent des API et différents protocoles de communication : REST, gRPC, WebSocket, HTTP/3, QUIC ou encore UDP.
Ces termes sont souvent présentés comme des technologies concurrentes. En réalité, ils ne jouent pas tous le même rôle. Certains décrivent la manière de formuler une demande, d’autres la façon de la transporter. Les comprendre permet surtout d’éviter une erreur fréquente : choisir une technologie parce qu’elle semble moderne, alors qu’elle ne répond pas au problème rencontré.
Une API n’est pas le tuyau qui transporte les données
Commençons par l’API. On peut l’imaginer comme le comptoir d’accueil d’une entreprise. Elle indique ce qu’il est possible de demander, sous quelle forme et avec quelles autorisations.
Une application peut ainsi demander :
- la liste des clients ;
- la création d’une commande ;
- l’état d’une livraison ;
- la modification d’une adresse.
L’API constitue donc un contrat de communication. Elle définit les demandes acceptées et la forme des réponses. Mais elle ne dit pas, à elle seule, comment les informations voyagent sur le réseau.
C’est là qu’interviennent REST, gRPC, HTTP, QUIC ou WebSocket. Pour reprendre notre comparaison, l’API est le comptoir et son catalogue de services. Les protocoles organisent la conversation et acheminent les messages.
REST : la conversation que presque tout le monde comprend
REST est aujourd’hui la manière la plus répandue de concevoir une API web. Techniquement, ce n’est pas un protocole, mais un style d’architecture généralement utilisé avec HTTP.
Son fonctionnement est assez naturel. Une adresse représente une ressource et les méthodes HTTP expriment l’action souhaitée :
GETpour consulter ;POSTpour créer ;PUTouPATCHpour modifier ;DELETEpour supprimer.
Les données sont souvent échangées au format JSON, un texte structuré qu’un humain peut encore lire. C’est l’une des grandes forces de REST : un développeur peut ouvrir une requête, comprendre ce qui a été envoyé et identifier assez rapidement l’origine d’une erreur.
REST est également très bien pris en charge par les navigateurs, les applications mobiles, les outils d’intégration et la quasi-totalité des langages. Pour une application de gestion, un portail client ou une API destinée à des partenaires, c’est souvent le choix le plus raisonnable.
Cette simplicité possède toutefois un coût. Le JSON peut devenir volumineux. Certaines pages doivent enchaîner plusieurs appels. Et si le contrat est mal documenté, le frontend et le backend peuvent finir par ne plus attendre exactement les mêmes données.
Une API REST devient donc beaucoup plus robuste lorsqu’elle est versionnée, documentée avec un standard comme OpenAPI et accompagnée de règles claires sur les erreurs, les droits et les formats de données.
Les avantages de REST : simplicité, compatibilité universelle, lisibilité, facilité de test et bonne adaptation aux API publiques.
Ses limites : messages parfois plus lourds, multiplication possible des appels et contrats moins stricts lorsqu’ils sont insuffisamment documentés.
gRPC : quand deux services doivent se parler vite et précisément
gRPC adopte une autre philosophie. Au lieu de manipuler principalement des adresses et des documents JSON, on définit des opérations et des messages dans un contrat formel, généralement écrit avec Protocol Buffers.
À partir de ce contrat, les outils peuvent générer automatiquement une partie du code nécessaire côté client et côté serveur. Les deux interlocuteurs savent précisément quels champs sont attendus, lesquels sont obligatoires et quel type de réponse sera renvoyé.
Les messages sont binaires. Ils sont donc généralement plus compacts et plus rapides à traiter que du JSON. gRPC gère aussi très bien le streaming : le serveur peut envoyer une suite de réponses sans recréer une nouvelle conversation à chaque fois.
C’est particulièrement intéressant lorsqu’un système est composé de plusieurs services internes très sollicités. Par exemple, un service de tarification peut interroger plusieurs milliers de fois par minute un service de catalogue ou de disponibilité.
Mais gRPC n’est pas automatiquement « meilleur » que REST. Un message binaire est moins facile à lire à l’œil nu. L’utilisation directe depuis un navigateur demande souvent une couche adaptée, comme gRPC-Web ou un proxy compatible. L’exploitation et le débogage réclament également des outils spécifiques.
Dans une application encore organisée en monolithe modulaire, remplacer de simples appels internes par gRPC peut surtout ajouter de la complexité sans apporter de gain visible à l’utilisateur.
Les avantages de gRPC : performances, messages compacts, contrats fortement typés, génération de code et streaming efficace.
Ses limites : débogage moins immédiat, intégration web plus délicate et complexité rarement justifiée pour une application simple ou une API publique.
WebSocket : garder la ligne ouverte
Avec une API REST classique, le client pose une question et le serveur répond. Puis l’échange se termine. Pour connaître une évolution, le client doit poser une nouvelle question.
WebSocket permet au contraire de garder la connexion ouverte. Une fois le canal établi, le client et le serveur peuvent s’envoyer des messages dans les deux sens, à tout moment.
C’est utile pour une messagerie instantanée, une édition collaborative, le suivi en direct d’une opération ou l’apparition immédiate d’une notification. Le serveur n’a plus besoin d’attendre que le navigateur lui demande s’il y a du nouveau : il peut pousser directement l’information.
Cette fluidité a un revers. Il faut maintenir les connexions, gérer les coupures, reconnecter les utilisateurs, éviter les messages en double et répartir correctement les connexions lorsque plusieurs serveurs fonctionnent ensemble. Pour créer ou modifier une fiche client, une API REST reste généralement plus simple. WebSocket doit être réservé aux fonctions qui ont réellement besoin du temps réel.
UDP : envoyer rapidement, sans demander de reçu
UDP se situe plus bas dans la mécanique du réseau. Ce n’est pas une façon de construire une API métier, mais un protocole de transport.
Son principe est minimaliste : un paquet est envoyé sans établir une longue conversation au préalable et sans garantie intégrée qu’il arrivera, qu’il arrivera dans le bon ordre ou qu’il n’arrivera pas deux fois.
Cela peut sembler peu rassurant, mais cette légèreté est très utile lorsque la rapidité compte davantage que la récupération de chaque paquet. Dans un appel vidéo, par exemple, il vaut souvent mieux perdre une fraction de seconde de son que bloquer toute la conversation en attendant sa retransmission. UDP est aussi utilisé dans les jeux en ligne, certaines communications temps réel et les requêtes DNS.
Pour une API de facturation, de stock ou de paiement, utiliser directement UDP serait en revanche une mauvaise idée. Il faudrait reconstruire soi-même les mécanismes de fiabilité, de sécurité, d’ordre et de reprise.
QUIC : partir d’UDP pour reconstruire un transport moderne
QUIC utilise UDP comme fondation, mais il ne reprend pas son absence de garanties. Il ajoute les éléments nécessaires à une communication web fiable : gestion des connexions, retransmission des données perdues, contrôle de congestion, flux multiples et chiffrement intégré avec TLS 1.3.
L’un de ses principaux intérêts apparaît lorsque le réseau devient imparfait. Avec certaines communications basées sur TCP, la perte d’un paquet peut retarder d’autres échanges qui n’ont pourtant rien à voir. QUIC sépare mieux les flux : si l’un rencontre un problème, les autres peuvent continuer à avancer.
Il gère également mieux les changements de réseau. Un smartphone peut passer du Wi-Fi à la 5G sans devoir nécessairement reconstruire toute la connexion comme auparavant. Dans la vie réelle, où les utilisateurs se déplacent et où les réseaux sont rarement parfaits, cela peut améliorer la sensation de rapidité.
QUIC reste toutefois plus complexe à observer et à diagnostiquer que les protocoles historiques. Certains pare-feu, équipements réseau ou outils de supervision anciens le comprennent moins bien. Dans la plupart des projets, il est pris en charge par le navigateur, le serveur web, le CDN ou le proxy : l’application métier n’a pas à le réimplémenter.
HTTP/3 : le Web adopte QUIC
HTTP/3 est la version d’HTTP conçue pour fonctionner sur QUIC, alors que HTTP/1.1 et HTTP/2 utilisent généralement TCP.
La relation entre ces technologies peut se résumer ainsi :
API REST classique → HTTP/1.1 ou HTTP/2 → TCP → IP
API via HTTP/3 → HTTP/3 → QUIC → UDP → IP
gRPC classique → HTTP/2 → TCP → IPUne API REST peut donc parfaitement être transportée par HTTP/3. REST et HTTP/3 ne sont pas des concurrents : REST structure l’API, tandis qu’HTTP/3 contribue à transporter les requêtes.
Pour l’utilisateur, les bénéfices d’HTTP/3 se ressentent surtout sur les connexions mobiles, les réseaux avec de la latence ou ceux qui perdent régulièrement des paquets. Sur un réseau local stable, la différence peut être imperceptible.
Son principal avantage est qu’il peut souvent être activé au niveau de l’infrastructure sans réécrire l’application. Son inconvénient est qu’il ajoute une couche technique à surveiller et que ses gains ne sont pas identiques dans tous les contextes.
Des technologies complémentaires, pas une compétition
| Technologie | Rôle principal | Idéale pour | Principal avantage | Principal inconvénient |
|---|---|---|---|---|
| REST/JSON | Concevoir une API web | Applications métier, mobiles et API partenaires | Simple et universel | Échanges parfois plus volumineux |
| gRPC | Appeler des fonctions distantes | Communications internes à fort volume | Rapide et fortement typé | Moins naturel dans un navigateur |
| WebSocket | Maintenir un canal bidirectionnel | Chat, collaboration et notifications en direct | Véritable temps réel | Connexions plus complexes à exploiter |
| UDP | Transporter des paquets avec très peu de surcharge | Voix, vidéo, jeux et télémétrie | Très faible latence | Aucune garantie native de livraison |
| QUIC | Fournir un transport moderne sur UDP | Connexions web mobiles ou instables | Rapidité, sécurité et flux indépendants | Diagnostic et infrastructure plus exigeants |
| HTTP/3 | Transporter le Web sur QUIC | Sites et API accessibles sur Internet | Meilleure résistance aux réseaux imparfaits | Gain parfois faible sur un réseau stable |
Alors, que faut-il choisir pour une API ?
Pour la majorité des applications métier, le bon point de départ reste une API REST bien conçue, échangée en HTTPS et documentée avec précision. Elle est facile à intégrer, à tester et à faire évoluer. HTTP/2 ou HTTP/3 peuvent ensuite améliorer le transport sans modifier les principes de l’API.
gRPC mérite d’être envisagé lorsque plusieurs services indépendants communiquent très fréquemment, que les volumes deviennent importants et qu’un contrat strict apporte une vraie valeur. Pas simplement parce qu’il est réputé plus rapide.
WebSocket est pertinent lorsqu’une fonctionnalité perd son intérêt sans mise à jour instantanée. Il peut alors compléter REST : l’API classique gère les opérations métier, tandis que WebSocket transmet les événements en direct.
Quant à UDP et QUIC, ils appartiennent surtout à la couche de transport. Une application de gestion n’a généralement aucune raison de manipuler UDP directement. QUIC et HTTP/3 seront plus souvent activés et administrés par l’infrastructure qui expose l’application sur Internet.
La meilleure architecture est souvent celle que l’équipe peut encore comprendre
Dans la technologie, les nouveautés ont toujours quelque chose de séduisant. Un protocole plus rapide, un format plus compact ou une architecture plus distribuée donnent facilement l’impression de préparer l’avenir.
Mais chaque technologie ajoutée devient aussi une technologie à sécuriser, superviser, expliquer et maintenir. Une architecture n’est pas moderne parce qu’elle accumule les protocoles. Elle l’est lorsqu’elle répond efficacement aux besoins présents tout en laissant une porte ouverte aux évolutions futures.
Le bon choix n’est donc pas « REST ou gRPC pour toujours », ni « HTTP/3 à tout prix ». C’est souvent : REST tant que sa simplicité suffit, WebSocket là où le temps réel apporte une vraie valeur, gRPC lorsque les échanges internes l’exigent réellement, et HTTP/3 lorsque l’infrastructure et les usages réseau permettent d’en tirer profit.
Autrement dit, le meilleur protocole n’est pas le plus impressionnant sur un schéma d’architecture. C’est celui qui rend la communication fiable pour l’utilisateur et compréhensible pour l’équipe qui devra encore la faire fonctionner dans trois ans.