gRPC vs REST : quand choisir quoi ?

REST est partout. gRPC monte en puissance. Mais lequel choisir pour votre prochain projet ? Spoiler : ce n'est pas une question de performance — c'est une question d'usage.

REST en 30 secondes

REST (Representational State Transfer) utilise HTTP + JSON. C'est le standard du web depuis 15 ans.

typescript// Client REST
const user = await fetch("https://api.example.com/users/123")
  .then(r => r.json());

// Serveur REST (Elysia)
app.get("/users/:id", ({ params }) => {
  return db.findUser(params.id);
});

Forces : universel, lisible, facile à débugger, fonctionne partout.

gRPC en 30 secondes

gRPC utilise HTTP/2 + Protocol Buffers (binaire). Développé par Google.

protobuf// Définition du service (user.proto)
service UserService {
  rpc GetUser (GetUserRequest) returns (User);
  rpc ListUsers (ListUsersRequest) returns (stream User);
}

message GetUserRequest {
  string id = 1;
}

message User {
  string id = 1;
  string name = 2;
  string email = 3;
}

Forces : typage fort, streaming, performance, génération de code.

Comparaison technique

Quand choisir REST ?

1. API publique / externe

Si des développeurs externes consomment votre API, REST est le choix évident :

• Tout le monde connaît REST
• Testable avec curl ou Postman
• Documentation avec OpenAPI/Swagger

2. Frontend web classique

Les navigateurs parlent HTTP + JSON nativement. Ajouter gRPC-web est une complexité inutile pour la plupart des apps.

3. CRUD simple

Si votre API fait principalement du Create/Read/Update/Delete :

GET    /users          → Liste
POST   /users          → Créer
GET    /users/:id      → Lire
PUT    /users/:id      → Modifier
DELETE /users/:id      → Supprimer

REST est parfait : lisible, prévisible, standardisé.

4. Équipe junior ou mixte

REST a une courbe d'apprentissage quasi nulle. Tout développeur web sait faire un appel REST.

Quand choisir gRPC ?

1. Communication inter-services (microservices)

C'est LE cas d'usage principal de gRPC :

┌──────────┐  gRPC  ┌──────────┐  gRPC  ┌──────────┐
│ Service A │──────→│ Service B │──────→│ Service C │
└──────────┘       └──────────┘       └──────────┘
       ↑                                      │
       └──────────────gRPC────────────────────┘

Les services internes n'ont pas besoin d'être "developer-friendly" comme une API publique. La performance et le typage comptent plus.

2. Streaming de données

gRPC supporte 4 types de streaming :

protobufservice DataService {
  // Unaire (classique)
  rpc GetData (Request) returns (Response);

  // Server streaming (le serveur envoie un flux)
  rpc WatchData (Request) returns (stream DataPoint);

  // Client streaming (le client envoie un flux)
  rpc UploadData (stream DataPoint) returns (Summary);

  // Bidirectionnel
  rpc SyncData (stream DataPoint) returns (stream DataPoint);
}

Cas d'usage : monitoring temps réel, logs en streaming, synchronisation de données.

3. Performance critique

Quand chaque milliseconde compte :

• Trading haute fréquence
• Gaming multijoueur
• IoT avec bande passante limitée

Le format binaire de Protobuf est 2-10x plus compact que JSON et plus rapide à (dé)sérialiser.

4. Contrat d'API strict

Le fichier .proto EST le contrat. Pas d'ambiguïté :

protobufmessage CreateOrderRequest {
  string product_id = 1;       // Obligatoire
  int32 quantity = 2;          // Obligatoire
  optional string coupon = 3;  // Optionnel, explicite
}

Le code client et serveur est généré automatiquement — impossible d'envoyer un mauvais type.

Mon approche hybride

Sur les projets que je développe, j'utilise souvent les deux :

Internet → [API Gateway REST] → Clients web/mobile
                    │
                    ▼
            [gRPC interne]
            ┌───┬───┬───┐
            │ A │ B │ C │  ← Microservices internes
            └───┴───┴───┘

• REST côté public (frontend, apps mobiles, partenaires)
• gRPC côté interne (communication inter-services)
• API Gateway qui traduit REST → gRPC

L'erreur classique : utiliser gRPC partout "parce que c'est plus performant". Si votre API sert 100 req/s à un frontend React, REST + JSON est parfait. Gardez gRPC pour là où il apporte une vraie valeur.

Checklist de décision

• API consommée par un navigateur ? → REST
• API publique pour des développeurs tiers ? → REST
• Communication entre microservices internes ? → gRPC
• Besoin de streaming bidirectionnel ? → gRPC
• Payload volumineux à haute fréquence ? → gRPC
• Équipe qui ne connaît pas Protobuf ? → REST (pour commencer)
• Besoin de typage strict inter-services ? → gRPC