REST vs RPC : Deux façons de concevoir une API

Vous concevez une API pour un nouveau service. Devriez-vous la modéliser autour de ressources avec des verbes HTTP, ou exposer des procédures que les clients appellent directement ? Il ne s’agit pas simplement d’un choix de protocole — c’est une décision fondamentale sur la façon dont vous pensez l’interface de votre système.

La conception d’API REST vs RPC représente deux mentalités distinctes, pas seulement deux technologies. Comprendre quand chaque approche excelle (et quand les combiner) vous évitera des maux de tête architecturaux à l’avenir.

La différence fondamentale de mentalité

REST pense en ressources. Vous avez des noms (utilisateurs, commandes, produits) et un ensemble fixe de verbes (GET, PUT, DELETE). L’URL identifie sur quoi vous opérez, et la méthode HTTP indique comment.

RPC pense en actions. Vous avez des procédures (createUser, processPayment, generateReport) que vous appelez avec des arguments. L’accent est mis sur ce que vous voulez faire, pas sur ce sur quoi vous opérez.

Aucune approche n’est intrinsèquement meilleure. Elles résolvent différents problèmes efficacement.

// REST : orienté ressources
GET /users/123
PUT /users/123 { "name": "Alice" }

// RPC : orienté actions  
POST /rpc/getUser { "id": 123 }
POST /rpc/updateUserName { "id": 123, "name": "Alice" }

Idées reçues à clarifier

REST n’est pas “juste du CRUD JSON”. Le vrai REST inclut des contraintes comme l’absence d’état, la capacité de mise en cache et les systèmes en couches. La plupart des “APIs REST” sont en réalité des APIs HTTP avec des URLs orientées ressources — ce qui convient, mais ce n’est pas la même chose.

RPC n’est pas dépassé. Les implémentations modernes comme gRPC et Connect alimentent des infrastructures critiques chez Google, Netflix et d’innombrables startups. gRPC fonctionne sur HTTP/2 et HTTP/3, avec un support de routage standard dans Kubernetes Gateway API.

APIs HTTP vs RPC n’est pas binaire. De nombreux systèmes en production utilisent REST en périphérie (APIs publiques, clients navigateur) et RPC en interne (communication service-à-service). Ce pattern hybride est de plus en plus courant.

Compromis pratiques qui comptent vraiment

Mise en cache et outillage HTTP

Le modèle de ressources de REST s’aligne naturellement avec la mise en cache HTTP. Une réponse GET /products/123 peut être mise en cache par les CDN, navigateurs et proxies sans configuration spéciale.

RPC utilise généralement POST pour tout, ce que l’infrastructure HTTP traite comme non-cacheable par défaut. Vous pouvez rendre RPC cacheable, mais cela nécessite un travail de conception explicite.

Sécurité des types et génération de code

Les frameworks RPC modernes comme gRPC (avec Protocol Buffers) et Connect fournissent un typage fort et une génération automatique de clients. Vous définissez votre service une fois, puis générez des clients pour TypeScript, Go, Python et plus encore.

REST dispose d’OpenAPI (maintenant en version 3.2, avec la 3.1 introduisant un alignement complet avec JSON Schema), qui offre une génération de code similaire. Mais le typage semble souvent ajouté après coup plutôt que natif.

Streaming et données en temps réel

gRPC supporte nativement le streaming bidirectionnel. REST nécessite des solutions de contournement — Server-Sent Events, WebSockets ou long-polling.

Pour les clients navigateur, RPC fonctionne généralement via gRPC-Web, le protocole compatible HTTP de Connect, ou le transcodage JSON. Ces solutions ajoutent de la complexité mais permettent des patterns de streaming que REST pur ne peut égaler.

Gestion des erreurs

Les APIs REST adoptent de plus en plus la RFC 9457 (Problem Details) pour des réponses d’erreur standardisées. Les frameworks RPC ont leurs propres modèles d’erreur — les codes de statut de gRPC, par exemple.

Les deux fonctionnent. La clé est la cohérence au sein de votre système.

Quand choisir quoi

Privilégiez REST quand :

• Vous construisez des APIs publiques consommées par des clients inconnus
• La mise en cache est critique pour les performances
• Vous voulez une compatibilité maximale avec l’outillage HTTP existant
• Vos opérations correspondent clairement au CRUD sur des ressources

Privilégiez RPC quand :

• Vous construisez des APIs internes service-à-service
• Vous avez besoin de streaming ou de communication bidirectionnelle
• Le typage fort et la génération de code sont des priorités
• Vos opérations sont véritablement procédurales (“redémarrer le serveur”, “lancer l’analyse”)

Utilisez les deux quand :

• Vous avez des APIs publiques (REST) et des microservices internes (RPC)
• Différentes parties de votre système ont des exigences différentes

La réalité hybride

La plupart des patterns d’architecture d’API modernes ne choisissent pas exclusivement une approche. Une configuration typique pourrait exposer une API REST via une passerelle API pour les consommateurs externes tout en utilisant gRPC entre services internes pour les performances et la sécurité des types.

Ce n’est pas un compromis — c’est utiliser le bon outil pour chaque contexte.

Conclusion

Commencez par vos contraintes. Qui consomme cette API ? Quelles opérations doit-elle supporter ? Quelle est l’importance de la mise en cache ? Avez-vous besoin de streaming ?

REST vs RPC ne concerne pas lequel est “meilleur”. Il s’agit de savoir quelle mentalité — ressources ou procédures — correspond mieux à votre problème. Souvent, la réponse est les deux.

FAQ

Truly understand users experience

See every user interaction, feel every frustration and track all hesitations with OpenReplay — the open-source digital experience platform. It can be self-hosted in minutes, giving you complete control over your customer data. . Check our GitHub repo and join the thousands of developers in our community..