Réponse.

Le choix du style architectural de l’API dépend des exigences en matière d’évolutivité, de vitesse, de flexibilité, de compatibilité et des spécificités des consommateurs de l'API.

• REST : Convient à la plupart des intégrations internes et externes en raison de sa simplicité (HTTP, JSON), des opérations idempotentes, du cache et d'un large soutien dans les outils.
• gRPC : Utilisé pour des performances élevées et un streaming bidirectionnel, une faible latence, un schéma strict (Protobuf). Idéal pour les services internes et les microservices où les exigences en matière de performances sont supérieures à celles de la compatibilité.
• GraphQL : Permet au client de choisir lui-même la structure des données. Idéal pour les clients mobiles externes et front-end lorsque la flexibilité et la minimisation du trafic sont requises.

Exemple de code (service gRPC en Go) :

// Description du protocole
service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// Implémentation
func (s *server) SayHello(ctx context.Context, req *pb.HelloRequest) (*pb.HelloReply, error) {
  return &pb.HelloReply{Message: "Hello " + req.Name}, nil
}

Caractéristiques clés :

• Différents styles architecturaux (REST, gRPC, GraphQL) répondent à différentes problématiques
• gRPC est préférable pour les API internes avec des exigences élevées en matière de vitesse et de typage
• GraphQL est optimal pour des API publiques complexes avec de nombreuses variations de requêtes et un grand nombre de consommateurs frontaux

Questions pièges.

Peut-on utiliser GraphQL pour remplacer tous les API REST ou gRPC ?

Non, GraphQL n'est pas toujours rationnel - il complique le cache, la journalisation, rend la protection de l’API plus difficile et peut être excessif pour des tâches simples où REST ou gRPC sont plus simples et plus fiables.

REST peut-il garantir un typage strict ?

Uniquement partiellement. REST est défini par la cohérence des contrats (Swagger/OpenAPI), mais par nature, il fonctionne avec des formats non stricts (JSON/HTTP), tandis que gRPC assure un typage statique robuste grâce au schéma Protobuf.

Dans quels cas gRPC n'est-il pas recommandé pour des API publiques ?

gRPC est moins compatible avec les navigateurs et s'intègre mal avec l'infrastructure HTTP/1.1 (par exemple, les proxies, les pare-feu). Pour les API web publiques, REST ou GraphQL sont préférables.