Pourquoi l'IA agentique a ressuscité JSON-RPC et ce que ça change pour vos APIs

JSON-RPC ne vient pas enterrer REST. REST reste le standard incontesté pour les API publiques, la manipulation de ressources et le web en général. Mais l'essor des agents IA a mis en lumière une limite fondamentale : REST est conçu pour exposer des ressources, pas pour orchestrer des actions.

C'est précisément ce créneau que JSON-RPC occupe — et que MCP a élevé au rang de standard industriel. Deux protocoles, deux philosophies, deux usages complémentaires.

1. JSON vs JSON-RPC : la différence fondamentale

Pour bien démarrer, il est crucial de séparer le contenant du contenu.

• JSON (le format) : C'est une syntaxe, une manière d'organiser des données {"clé": "valeur"}. Il est passif. C'est l'équivalent d'une simple liste de courses.
• JSON-RPC (le protocole) : C'est une règle de communication de type Remote Procedure Call. Il utilise le format JSON pour structurer une instruction envoyée d'une machine à une autre. C'est l'équivalent d'un bon de commande officiel envoyé à une usine.

Là où une API REST classique se concentre sur la manipulation de "ressources" (via les verbes HTTP GET, POST, PUT, DELETE), le JSON-RPC se concentre exclusivement sur des actions ou des fonctions.

2. La mécanique sous le capot

Une interaction JSON-RPC repose sur une spécification stricte (actuellement en version 2.0).

La Requête (le client demande)

Pour être valide, l'objet JSON envoyé au serveur doit contenir quatre éléments clés :

1. jsonrpc : La version du protocole ("2.0").
2. method : Le nom de la procédure distante à exécuter.
3. params : Les paramètres requis par la fonction (sous forme de tableau ou d'objet).
4. id : Un identifiant unique pour corréler la réponse asynchrone à la requête.

Exemple d'appel :

{
  "jsonrpc": "2.0",
  "method": "initierVirement",
  "params": {
    "ibanDestinataire": "FR76 3000 6000 0112 3456 7890 189",
    "montant": 1500.00,
    "devise": "EUR",
    "motif": "Facture #2024-042"
  },
  "id": "req-001"
}

Batch : plusieurs opérations en un seul appel (c'est ici que JSON-RPC brille vraiment)

[
  {
    "jsonrpc": "2.0",
    "method": "validerPaiement",
    "params": { "transactionId": "TXN-789" },
    "id": "req-001"
  },
  {
    "jsonrpc": "2.0",
    "method": "notifierClient",
    "params": { "clientId": "USR-456", "canal": "email" },
    "id": "req-002"
  },
  {
    "jsonrpc": "2.0",
    "method": "mettreAJourComptable",
    "params": { "transactionId": "TXN-789", "categorie": "SORTANT" },
    "id": "req-003"
  }
]

3. Pourquoi choisir JSON-RPC face à REST ?

Bien que REST soit le standard de facto pour les API publiques, JSON-RPC brille dans des cas d'usage spécifiques grâce à plusieurs avantages architecturaux :

4. REST vs JSON-RPC : comparaison par le code (Java / Spring Boot)

Pour rendre la différence d'architecture plus concrète, voici comment on implémenterait cette même fonctionnalité (vire) dans les deux paradigmes avec Spring Boot.

L'approche REST : routage par l'URL et le verbe HTTP

En REST, le point d'entrée est défini par le chemin de l'URL et la méthode HTTP utilisée.

@RestController
@RequestMapping("/api/paiements")
public class PaiementRestController {

    @PostMapping("/virement")
    public ResponseEntity<VirementDto> initierVirement(@RequestBody VirementRequest req) {
        // Si le solde est insuffisant → HTTP 400
        // Le monitoring alerte immédiatement ✓
        return paiementService.initier(req);
    }

    @PutMapping("/{id}/valider")
    public ResponseEntity<Void> valider(@PathVariable String id) { ... }

    @DeleteMapping("/{id}")
    public ResponseEntity<Void> annuler(@PathVariable String id) { ... }
}

L'approche JSON-RPC : un endpoint unique, routage par le payload

En JSON-RPC, il n'y a généralement qu'une seule URL pour toute l'API (ex: /rpc/paiements). C'est le contenu du message JSON qui dicte au serveur quelle méthode exécuter. Voici comment cela s'implémente souvent avec une librairie dédiée comme jsonrpc4j :

@JsonRpcService("/rpc/paiements")
public interface PaiementRpcService {

    @JsonRpcMethod("initierVirement")
    VirementDto initierVirement(
        @JsonRpcParam("ibanDestinataire") String iban,
        @JsonRpcParam("montant") BigDecimal montant,
        @JsonRpcParam("devise") String devise
    );

    @JsonRpcMethod("validerPaiement")
    void validerPaiement(@JsonRpcParam("transactionId") String id);

    @JsonRpcMethod("annulerTransaction")
    void annulerTransaction(@JsonRpcParam("transactionId") String id);
}

La grande différence : en REST, ajouter une nouvelle fonctionnalité demande souvent de créer une nouvelle route URL. En JSON-RPC, l'URL /rpc ne change jamais ; on se contente d'ajouter de nouvelles méthodes dans l'interface que le répartiteur (dispatcher) va lire.

5. Les 3 piliers de l'expertise : Erreurs, Sécurité et gRPC

A. La gestion des erreurs : Le piège du "200 OK"

C'est le point de vigilance majeur pour les Ops. En JSON-RPC, une erreur métier (ex: solde insuffisant) renverra quand même un code HTTP 200.

• L'erreur est encapsulée dans le payload avec des codes standards : -32601 (Méthode non trouvée), -32602 (Paramètres invalides), etc.

Le cas concret : un virement bancaire qui "réussit"… mais échoue

Du côté du monitoring naïf, tout semble normal :

HTTP/1.1 200 OK
Content-Type: application/json

Mais dans le corps de la réponse, l'erreur est bien là :

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32603,
    "message": "Solde insuffisant",
    "data": {
      "solde_actuel": 42.00,
      "montant_demande": 500.00
    }
  },
  "id": "req-001"
}

réponse de succès :

{
  "jsonrpc": "2.0",
  "result": {
    "transaction_id": "TXN-789",
    "statut": "validé"
  },
  "id": "req-001"
}

⚠️ Piège Ops : Un outil de monitoring qui alerte uniquement sur les codes HTTP 4xx/5xx sera aveugle à cette erreur. Les deux réponses retournent un 200 OK identique. Il faut impérativement configurer vos alertes pour parser le champ error du payload JSON.

B. Sécurité : Attention à l'exposition

Puisque vous appelez des fonctions par leur nom, un attaquant pourrait tenter d'appeler des méthodes internes.

• Validation : Utilisez une liste blanche (allow-list) stricte des méthodes exposées.
• Sanitisation : Les paramètres (params) doivent être validés aussi rigoureusement que des entrées de formulaire.

C. JSON-RPC vs gRPC : Pourquoi ne pas avoir choisi le binaire ?

gRPC est plus rapide (binaire) mais beaucoup plus rigide.

• JSON-RPC est auto-descriptif et lisible par un humain sans outils complexes.
• Dans le cadre des LLM (comme via MCP), pouvoir inspecter les messages en clair est crucial pour le débuggage et l'observabilité du comportement de l'IA.

6. Le renouveau : le Model Context Protocol (MCP)

C'est aujourd'hui l'application la plus stratégique du JSON-RPC. Le MCP (Model Context Protocol), introduit par Anthropic et massivement adopté par l'écosystème IA, est un standard open-source qui permet aux modèles de langage (LLMs) de se connecter de manière standardisée à des sources de données locales ou distantes.

Pourquoi MCP s'appuie sur JSON-RPC ?

Pour qu'une IA puisse utiliser un outil (comme lire un fichier sur votre disque dur ou interroger votre base PostgreSQL), elle a besoin d'un "langage de commande" universel, léger et bidirectionnel. JSON-RPC coche toutes les cases.

Dans l'architecture MCP, le client (l'application IA) et le serveur (l'outil) échangent des messages JSON-RPC pour trois types de capacités :

1. Resources : exposer des données au modèle (ex: le contenu d'un repo Git).
2. Prompts : fournir des templates de contexte pré-définis.
3. Tools : permettre au modèle d'exécuter des actions concrètes.

Exemple d'une IA déclenchant un outil via MCP :

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "query_database",
    "arguments": { "sql": "SELECT * FROM users LIMIT 5;" }
  },
  "id": 42
}

Les Transports MCP

Parce que JSON-RPC est agnostique au transport, MCP exploite plusieurs canaux selon l'environnement de déploiement :

• STDIO (Standard Input/Output) : utilisé pour les serveurs MCP exécutés localement sur la machine de l'utilisateur. Les messages JSON transitent directement dans les flux système.
• HTTP / SSE (Server-Sent Events) : utilisé pour interroger des serveurs MCP hébergés dans le cloud ou sur un réseau distant.

7. L'industrialisation : le cas Google Apigee

Le signe le plus flagrant de la maturité d'une technologie est son adoption par les solutions de gestion d'API (API Management). Lors de récentes démonstrations, Google Apigee a présenté son support natif pour JSON-RPC, avec une attention particulière portée au MCP.

Sécurité granulaire MCP : Pourquoi l'analyse du payload révolutionne l'API Management ?

Traditionnellement, les passerelles d'API (Gateways) sont conçues pour le modèle REST (une URL = une ressource). Le JSON-RPC, avec son endpoint unique /rpc, créait une "boîte noire" pour la sécurité. Google résout cela nativement pour MCP :

• Analyse intelligente du payload : La Gateway ne se contente plus de router un flux opaque. Elle décode la structure JSON-RPC pour identifier la méthode (method) et les paramètres (params) en temps réel, traitant chaque appel comme une opération distincte.
• Sécurité granulaire (Fine-grained Auth) : grâce à cette visibilité, les politiques de sécurité (OAuth, API Keys) s'appliquent au niveau de la fonction appelée et non plus seulement sur l'URL. On peut ainsi autoriser une IA à consulter un inventaire (tools/list) tout en lui interdisant formellement de supprimer une archive (tools/delete).
• Gouvernance dynamique des ressources : Pour les serveurs MCP, Apigee peut désormais filtrer dynamiquement les outils exposés. Lors de l'appel à tools/list, la Gateway intercepte la réponse pour ne laisser passer que les outils explicitement autorisés dans l'API Product de l'utilisateur.

Cela permet aux entreprises de déployer des serveurs MCP sécurisés et monitorés, avec le même niveau de rigueur que leurs APIs REST classiques.

⚠️ Quand ne pas utiliser JSON-RPC

JSON-RPC est un outil puissant, mais comme tout outil, il est inadapté hors de son domaine d'excellence. Voici les cas où REST ou gRPC restent le meilleur choix.

Vous exposez une API publique : REST est le standard attendu par l'écosystème. Les outils de documentation (Swagger, Postman), les API gateways, et les développeurs tiers connaissent REST. Imposer JSON-RPC sur une API publique crée une friction inutile sans gain réel.

Vous avez besoin du cache HTTP : Les requêtes JSON-RPC sont toutes des POST. Impossible de bénéficier nativement du cache HTTP (GET + ETag + Cache-Control). Si votre use case repose sur des données lues fréquemment et rarement modifiées, REST est plus performant sans infrastructure supplémentaire.

Votre solution est 100% orientée ressources : Si votre modèle de données est naturellement CRUD — des utilisateurs, des produits, des commandes — REST est plus lisible et maintenable. Forcer un modèle RPC sur des ressources crée une API artificielle et contre-intuitive.

Vous avez besoin de streaming haute performance : Pour du streaming bidirectionnel intensif entre microservices, gRPC (binaire + HTTP/2) surpasse JSON-RPC sur les performances brutes. JSON-RPC reste lisible mais paie le coût de la sérialisation JSON.

Conclusion

Le JSON-RPC est loin d'être un protocole du passé. Si la décennie précédente a été dominée par la standardisation des ressources via REST, l'ère de l'Intelligence Artificielle et des agents autonomes ramène le besoin d'exécuter des actions directes au premier plan. Que ce soit pour interagir avec des nœuds blockchain, ou pour concevoir des serveurs MCP capables d'armer vos IA avec vos propres outils d'entreprise, maîtriser JSON-RPC est redevenu une compétence incontournable.

Ce qui reste ouvert, c'est la question de votre propre stack : vos outils internes sont-ils déjà accessibles à vos agents IA ? Si ce n'est pas le cas, vous savez maintenant par où commencer.

#IA #Architecture #API #Apigee #MCP #REST #JSON-RPC