Partager via

Comparer les services gRPC avec les API HTTP

  • Article

Remarque

Ceci n’est pas la dernière version de cet article. Pour la version actuelle, consultez la version .NET 8 de cet article.

Avertissement

Cette version d’ASP.NET Core n’est plus prise en charge. Pour plus d’informations, consultez la Stratégie de prise en charge de .NET et .NET Core. Pour la version actuelle, consultez la version .NET 8 de cet article.

Important

Ces informations portent sur la préversion du produit, qui est susceptible d’être en grande partie modifié avant sa commercialisation. Microsoft n’offre aucune garantie, expresse ou implicite, concernant les informations fournies ici.

Pour la version actuelle, consultez la version .NET 8 de cet article.

Par James Newton-King

Cet article explique les avantages des services gRPC par rapport aux API HTTP avec JSON (y compris des API web ASP.NET Core). La technologie utilisée pour fournir une API pour votre application est un choix important et gRPC offre des avantages uniques par rapport aux API HTTP. Cet article décrit les forces et les faiblesses de gRPC et recommande des scénarios dans lesquels utiliser gRPC par rapport à d’autres technologies.

Comparaison non détaillée

Le tableau suivant offre une comparaison non détaillée des fonctionnalités entre les API gRPC et HTTP avec JSON.

Fonctionnalité gRPC API HTTP avec JSON
Contrat Obligatoire (.proto) Facultatif (OpenAPI)
Protocol HTTP/2 HTTP
Payload Protobuf (petit, binaire) JSON (grand, lisible par l’homme)
Prescriptivité Spécification stricte Lâche. Tout HTTP est valide.
Diffusion en continu Client, serveur, bidirectionnel Client, serveur
Prise en charge des navigateurs Non (nécessite grpc-web) Oui
Sécurité Transport (TLS) Transport (TLS)
Génération de code client Oui OpenAPI + outils tiers

Points forts de gRPC

Performances

Les messages gRPC sont sérialisés à l’aide de Protobuf, un format de message binaire efficace. Protobuf sérialise très rapidement sur le serveur et le client. La sérialisation de Protobuf génère de petites charges utiles de message, ce qui est important lorsque la bande passante est limitée, comme dans les applications mobiles.

gRPC est conçu pour HTTP/2, une révision majeure de HTTP qui offre des avantages significatifs en matière de performances par rapport à HTTP 1.x :

  • Cadrage binaire et compression. Le protocole HTTP/2 est compact et efficace à la fois pour l’envoi et la réception.
  • Multiplexage de plusieurs appels HTTP/2 sur une seule connexion TCP. Le multiplexage élimine le blocage de la tête de ligne.

HTTP/2 n’est pas exclusif à gRPC. De nombreux types de requêtes, y compris les API HTTP avec JSON, peuvent utiliser HTTP/2 et tirer parti de ses améliorations de performances.

Génération de code

Toutes les infrastructures gRPC fournissent une prise en charge de première classe pour la génération de code. Le fichier .proto est un fichier important pour le développement gRPC. Il définit le contrat des services et des messages gRPC. À partir de ce fichier, les infrastructures gRPC génèrent une classe de base de service, des messages et un client complet.

En partageant le fichier .proto entre le serveur et le client, les messages et le code client peuvent être générés de bout en bout. La génération de code du client élimine la duplication des messages sur le client et le serveur, et crée un client fortement typé pour vous. Le fait de ne pas avoir à écrire un client permet d’économiser beaucoup de temps de développement dans les applications avec de nombreux services.

Spécification stricte

Il n’existe pas de spécification formelle pour l’API HTTP avec JSON. Les développeurs discutent du meilleur format d’URL, de verbes HTTP et de codes de réponse.

La spécification gRPC est normative quant au format que doit suivre un service gRPC. gRPC supprime les débats et fait gagner du temps aux développeurs, car gRPC est cohérent entre les plateformes et les implémentations.

Diffusion en continu

HTTP/2 fournit une base pour les flux de communication en temps réel de longue durée. gRPC fournit une prise en charge de première classe pour la diffusion en continu via HTTP/2.

Un service gRPC prend en charge toutes les combinaisons de streaming :

  • Unaire (pas de diffusion en continu)
  • Diffuser en continu de serveur à client
  • Diffuser en continu de client à serveur
  • Diffusion en continu bidirectionnelle

Échéance/expiration et annulation

gRPC permet aux clients de spécifier la durée pendant laquelle ils sont prêts à attendre la fin d’un RPC. L’échéance est envoyée au serveur et le serveur peut décider de l’action à entreprendre s’il dépasse l’échéance. Par exemple, le serveur peut annuler les requêtes gRPC/HTTP/base de données en cours lors de l’expiration du délai.

La propagation de l’échéance et de l’annulation par le biais d’appels gRPC enfants permet d’appliquer les limites d’utilisation des ressources.

gRPC convient parfaitement aux scénarios suivants :

  • Microservices : gRPC est conçu pour une faible latence et une communication à haut débit. gRPC est idéal pour les microservices légers où l’efficacité est essentielle.
  • Communication point à point en temps réel : gRPC offre une excellente prise en charge de la diffusion en continu bidirectionnelle. Les services gRPC peuvent envoyer des messages en temps réel sans interrogation.
  • Environnements polyglottes : les outils gRPC prennent en charge tous les langages de développement courants, ce qui fait de gRPC un bon choix pour les environnements multilingues.
  • Environnements restreints en réseau : les messages gRPC sont sérialisés avec Protobuf, un format de message léger. Un message gRPC est toujours plus petit qu’un message JSON équivalent.
  • Communication inter-processus (IPC) : les transports IPC tels que les sockets de domaine Unix et les canaux nommés peuvent être utilisés avec gRPC pour communiquer entre les applications sur la même machine. Pour plus d’informations, consultez Communication interprocessus avec gRPC.

Points faibles de gRPC

Support du navigateur limité

Il n’est aujourd’hui pas possible d’appeler directement un service gRPC à partir d’un navigateur. gRPC utilise intensément les fonctionnalités HTTP/2 et aucun navigateur ne fournit le niveau de contrôle requis sur les requêtes web pour prendre en charge un client gRPC. Par exemple, les navigateurs n’autorisent pas un appelant à exiger l’utilisation de HTTP/2 ou à fournir l’accès aux images HTTP/2 sous-jacentes.

Sur ASP.NET Core, gRPC offre deux solutions compatibles avec les navigateurs :

  • gRPC-Web permet aux applications de navigateur d’appeler des services gRPC avec le client gRPC-Web et Protobuf. gRPC-Web nécessite que l’application de navigateur génère un client gRPC. gRPC-Web permet aux applications de navigateur de tirer parti d’une utilisation réseau faible et à hautes performances de gRPC.

    .NET intègre la prise en charge de gRPC-Web. Pour plus d’informations, consultez gRPC-Web dans les applications ASP.NET Core gRPC.

  • Le transcodage gRPC JSON permet aux applications de navigateur d’appeler des services gRPC comme s’il s’agissait d’API RESTful avec JSON. L’application de navigateur n’a pas besoin de générer un client gRPC ou de savoir quoi que ce soit sur gRPC. Les API RESTful peuvent être automatiquement créées à partir des services gRPC en annotant le fichier .proto avec des métadonnées HTTP. Le transcodage permet à une application de prendre en charge les API Web gRPC et JSON sans dupliquer l’effort de création de services distincts pour les deux.

    .NET intègre la prise en charge de la création d’API Web JSON à partir des services gRPC. Pour plus d’informations, consultez Transcodage JSON gRPC dans les applications ASP.NET Core gRPC.

Remarque

Le transcodage JSON gRPC nécessite .NET 7 ou version ultérieure.

Non lisible par l’homme

Les requêtes d’API HTTP sont envoyées sous forme de texte et peuvent être lues et créées par l’homme.

Par défaut, les messages gRPC sont encodés avec Protobuf. Bien que Protobuf soit efficace pour envoyer et recevoir des messages, son format binaire n’est pas lisible par l’homme. Protobuf nécessite que la description de l’interface du message spécifiée dans le fichier .proto soit correctement désérialisée. Des outils supplémentaires sont nécessaires pour analyser les charges utiles Protobuf sur le réseau et composer manuellement les demandes.

Il existe des fonctionnalités pour faciliter les messages Protobuf binaires, par exemple la réflexion du serveur et l’outil en ligne de commande gRPC. En outre, les messages Protobuf prennent en charge la conversion vers et depuis JSON. La conversion JSON intégrée offre un moyen efficace de convertir des messages Protobuf vers et à partir d’un formulaire lisible par l’homme lors du débogage.

Autres scénarios d’infrastructure

D’autres infrastructures que gRPC sont recommandées dans les scénarios suivants :

  • API accessibles par le navigateur : gRPC n’est pas entièrement pris en charge dans le navigateur. gRPC-Web peut offrir la prise en charge des navigateurs, mais il présente des limitations et introduit un proxy de serveur.
  • Diffuser la communication en temps réel : gRPC prend en charge la communication en temps réel via la diffusion en continu, mais le concept de diffusion d’un message aux connexions inscrites n’existe pas. Par exemple, dans le cas d’une salle de conversation où de nouveaux messages de conversation doivent être envoyés à tous les clients de la salle de conversation, chaque appel gRPC est requis pour diffuser individuellement de nouveaux messages de conversation au client. SignalR est une infrastructure utile pour ce scénario. SignalR a le concept de connexions persistantes et de prise en charge intégrée pour la diffusion de messages.

Ressources supplémentaires