État des protocoles d’API en 2023

• Tendances des protocoles d’API ainsi que leurs avantages/inconvénients, synthétisés par Postman à partir d’une enquête menée auprès de 40 000 développeurs
• REST, WebHooks, GraphQL, SOAP, WebSocket, gRPC, etc.

REST

• Reste le plus largement utilisé. En baisse de 92 % à 86 % au cours des deux dernières années
• Simplicité, évolutivité et facilité d’intégration avec les services web
• Avantages de REST
  • Simplicité et standardisation : en utilisant les méthodes HTTP standard, REST peut être adopté facilement par des développeurs déjà familiers avec HTTP. Cette simplicité favorise un apprentissage et une intégration rapides
  • Évolutivité : grâce au caractère sans état de REST, le serveur n’a pas besoin de stocker des données de session entre les requêtes. Cela facilite la montée en charge horizontale en ajoutant des instances sans serveur partagé
  • Performance : le modèle sans état et les réponses pouvant être mises en cache améliorent la vitesse d’exécution et réduisent le nombre de requêtes
  • Modularité : les services RESTful peuvent être développés sous forme de composants modulaires. Cela permet des mises à jour indépendantes et améliore la maintenabilité
  • Indépendance vis-à-vis des plateformes : utilisable avec divers clients. L’interopérabilité facilite l’intégration des API à travers les systèmes
  • Outils matures et support de la communauté : il existe de nombreux outils, bibliothèques, bonnes pratiques, guides de résolution de problèmes et ressources communautaires
• Limites de REST
  • Over-fetching et under-fetching : comme le client peut n’avoir besoin que d’une partie des données, il peut récupérer trop ou pas assez d’informations. Cela peut entraîner des problèmes de performance et gaspiller de la bande passante
  • Multiplication des interfaces : plusieurs requêtes peuvent être nécessaires pour récupérer des données liées, ce qui augmente la latence. Cette succession d’appels devient problématique à mesure que l’application monte en charge
  • Problèmes de versioning : créer une nouvelle version d’une API REST peut être fastidieux, surtout lorsque la structure des données ou les fonctionnalités du service changent. Cela entraîne souvent des problèmes de compatibilité avec les versions précédentes
  • Surcharge liée à l’absence d’état : si le modèle sans état favorise l’évolutivité, il signifie aussi que chaque requête doit fournir tout le contexte nécessaire. Cela peut créer un surcoût, notamment quand le client doit transmettre de gros volumes de données répétitives
  • Manque de capacités temps réel : REST n’est pas optimisé pour les applications temps réel comme le chat ou les flux en direct. WebSocket et SSE sont mieux adaptés à ces cas d’usage

WebHooks

• Les webhooks sont des callbacks HTTP personnalisés déclenchés par des événements dans l’application source
• Lorsqu’un événement se produit, l’application source envoie une requête HTTP (généralement POST) à l’URI indiqué par l’application cible, ce qui permet une communication quasi temps réel basée sur les événements sans polling répétitif
• Les webhooks gagnent en popularité, et 36 % des développeurs les utilisent pour une intégration fluide entre différents systèmes
• Avantages des WebHooks
  • Communication en temps réel : les webhooks permettent la transmission de données en temps réel. Lorsqu’un événement se produit, les données correspondantes sont envoyées, garantissant une synchronisation à jour entre les systèmes
  • Efficacité : les webhooks éliminent le polling gourmand en ressources, ce qui économise la puissance de calcul et la bande passante
  • Flexibilité : les webhooks peuvent être configurés pour répondre à des événements spécifiques, ce qui permet de définir quelles actions ou quels déclencheurs d’une application enverront des données à une autre
  • Intégration simplifiée : en utilisant les méthodes HTTP, ils peuvent être mis en œuvre facilement dans la plupart des applications
  • Support d’architectures découplées : les webhooks fonctionnent sur la base d’événements et soutiennent donc naturellement des architectures orientées événements ou découplées, améliorant modularité et évolutivité
• Limites des WebHooks
  • Gestion des erreurs : si le récepteur du webhook est indisponible ou si le traitement du callback échoue, il existe un risque de perte de données. Les systèmes utilisant des webhooks doivent disposer de mécanismes robustes de gestion des erreurs, incluant des tentatives de réexécution ou des journaux
  • Problèmes de sécurité : comme les webhooks transmettent des données via Internet, ils sont vulnérables à l’interception ou aux attaques malveillantes. Des mesures de sécurité API comme HTTPS et la signature du payload sont indispensables
  • Gestion de multiples webhooks : l’administration et la supervision des webhooks peuvent être complexes, en particulier à mesure que l’application grandit et dépend de plusieurs webhooks. Il faut veiller à ce qu’ils fonctionnent tous correctement et suivre les différents endpoints
  • Risque de surcharge : un grand volume de callbacks simultanés peut mettre à rude épreuve la réception côté application, même si le rate limiting ou le traitement par lots peut aider à gérer les pics

GraphQL

• GraphQL est un langage de requête pour les API ainsi qu’un runtime côté serveur permettant d’exécuter ces requêtes à l’aide d’un système de types défini sur les données
• Développé par Facebook en 2012 puis publié en open source en 2015, GraphQL propose une alternative plus flexible et plus efficace aux API REST traditionnelles
• Son taux d’adoption atteint 29 % parmi les développeurs, ce qui reflète son importance croissante dans le paysage actuel des API
• Contrairement à REST, qui impose souvent de passer par plusieurs endpoints API pour récupérer des données liées, GraphQL permet d’obtenir toutes les données nécessaires en une seule requête
• Cela est particulièrement utile pour les développeurs frontend, car ils disposent d’un meilleur contrôle sur le processus de récupération des données et peuvent créer des interfaces utilisateur plus dynamiques et réactives
• Avantages de GraphQL
  • Schéma fortement typé : une API GraphQL dispose d’un schéma fortement typé, ce qui permet aux développeurs de savoir exactement quelles données et quels types sont disponibles pour les requêtes
  • Récupération précise des données : le client peut demander exactement les données nécessaires, ce qui résout les problèmes d’over-fetching et d’under-fetching, améliore les performances et réduit les coûts
  • Complexité des requêtes et diversité des ressources : GraphQL permet d’interroger plusieurs types de données en une seule requête, ce qui réduit le nombre d’appels réseau pour des données complexes et interconnectées
  • Mises à jour en temps réel via les subscriptions : GraphQL prend en charge la synchronisation en temps réel grâce aux subscriptions, permettant aux clients d’être mis à jour en temps réel
  • Introspection : le schéma auto-documenté de GraphQL facilite le développement grâce à l’inspection intégrée
• Limites de GraphQL
  • Complexité des requêtes : la flexibilité offerte par GraphQL aux clients a un revers. Des requêtes trop complexes ou trop imbriquées peuvent nuire aux performances
  • Courbe d’apprentissage : GraphQL présente une courbe d’apprentissage plus raide que REST en raison de nouveaux concepts comme les mutations et les subscriptions
  • Versioning : la nature flexible des requêtes signifie que des changements de schéma peuvent casser des requêtes existantes, ce qui complique le versioning
  • Risque de surconsommation des ressources : comme les clients peuvent demander plusieurs ressources dans une seule requête, ils risquent de récupérer plus de données que nécessaire et de surcharger le serveur
  • Problèmes de sécurité : des utilisateurs malveillants peuvent exploiter la flexibilité de GraphQL pour surcharger le serveur avec des requêtes complexes

SOAP

• SOAP (Simple Object Access Protocol) est un protocole d’échange d’informations structurées pour implémenter des services web
• Il utilise XML comme format de message et s’appuie généralement sur HTTP ou SMTP comme couche de négociation et de transport des messages
• Contrairement à REST et GraphQL, SOAP dispose de standards stricts et de fonctionnalités intégrées comme les transactions compatibles ACID, la sécurité et les modèles de messagerie
• Malgré une utilisation en recul à seulement 26 % des développeurs, SOAP reste un choix fiable pour certaines applications
• Avantages de SOAP
  • Typage fort et contrat : il repose sur un typage fort et un contrat strict définis dans des documents WDSL (Web Services Description Language)
  • Fonctions de sécurité intégrées : SOAP fournit une sécurité complète via authentification, autorisation et chiffrement, implémentés à travers le standard WS-Security. Cela en fait un choix privilégié pour les applications d’entreprise
  • Transactions ACID : SOAP prend en charge les transactions ACID, essentielles pour les applications où l’intégrité des données est critique, comme la finance ou la santé
  • Messagerie fiable : SOAP garantit une livraison fiable des messages et gère bien les erreurs, ce qui le rend adapté aux systèmes où la garantie de livraison est cruciale
  • Neutralité vis-à-vis du langage, de la plateforme et du transport : comme REST, les services SOAP peuvent être utilisés par tout client comprenant XML, indépendamment du langage de programmation, de la plateforme ou du protocole de transport sous-jacent
• Limites de SOAP
  • Complexité et courbe d’apprentissage : SOAP peut être plus complexe à implémenter en raison de ses standards stricts et de l’usage de XML, ce qui implique une courbe d’apprentissage plus raide que des alternatives comme REST ou GraphQL
  • Messages verbeux : les en-têtes de message SOAP ajoutent beaucoup d’overhead, ce qui rend les payloads plus lourds que le JSON de REST et GraphQL. Cela peut affecter les performances et l’utilisation de la bande passante
  • Support communautaire limité : SOAP perd du terrain, ce qui signifie moins de support communautaire et moins de bibliothèques disponibles
  • Moins de flexibilité : lorsqu’un contrat change, le client comme le serveur peuvent devoir mettre à jour leur implémentation respective, ce qui peut être un inconvénient
  • Problèmes avec les pare-feu : SOAP peut utiliser des protocoles de transport différents de HTTP/HTTPS, ce qui peut se heurter à des restrictions de pare-feu. Cela réduit sa polyvalence dans certains environnements de déploiement

WebSocket

• WebSocket fournit une connexion bidirectionnelle persistante et à faible latence entre client et serveur, permettant le transfert de données en temps réel
• Contrairement au cycle requête-réponse de HTTP, WebSocket permet au serveur d’envoyer des données au client à tout moment après le handshake initial
• Il facilite les mises à jour de données immédiates pour les applications de chat, les jeux en ligne, les plateformes de trading, etc.
• Selon l’enquête, 25 % des développeurs utilisent WebSocket
• Avantages de WebSocket
  • Communication bidirectionnelle en temps réel : une communication bidirectionnelle en temps réel présente une latence plus faible qu’une connexion HTTP qu’il faut rétablir à chaque échange
  • Réduction des frais généraux : après le handshake initial, la connexion reste ouverte, ce qui réduit l’overhead des en-têtes associés aux requêtes HTTP classiques
  • Utilisation efficace des ressources : une connexion persistante utilise les ressources serveur plus efficacement que le long polling
• Limites de WebSocket
  • Complexité d’implémentation : mettre en œuvre WebSocket peut être plus complexe et plus long que d’autres architectures API, surtout lorsqu’il faut prévoir des solutions de repli dans les environnements qui ne le prennent pas en charge
  • Manque de fonctionnalités intégrées : contrairement à SOAP, qui intègre des fonctions de sécurité et de transaction, WebSocket est proche du bare metal et oblige les développeurs à implémenter eux-mêmes ces capacités
  • Consommation de ressources : les connexions WebSocket ouvertes sont généralement plus efficaces que les techniques de long polling, mais elles consomment tout de même des ressources serveur, ce qui peut devenir problématique à grande échelle
  • Limitations réseau : certains proxys et pare-feu ne prennent pas en charge WebSocket, ce qui peut provoquer des problèmes de connexion dans certains environnements réseau

gRPC

• gRPC, qui signifie « Google Remote Procedure Call », est un protocole moderne haute performance facilitant la communication entre services
• Construit au-dessus de HTTP/2, il utilise les protocol buffers pour définir les méthodes de service et les formats de message
• Contrairement aux API REST qui utilisent des verbes HTTP standard comme GET et POST, gRPC permet aux services d’exposer des méthodes personnalisées comparables aux fonctions d’un langage de programmation
• Avantages de gRPC
  • Performance : grâce à HTTP/2 et aux protocol buffers, gRPC peut atteindre une faible latence et un débit élevé
  • Typage fort : comme SOAP et GraphQL, gRPC est fortement typé. Les types sont donc validés à la compilation, ce qui réduit les bugs
  • Support multilingue : gRPC prend très bien en charge de nombreux langages de programmation, notamment Go, Java, C# et Node.js
  • Streaming : gRPC gère nativement les flux de requêtes et de réponses, ce qui le rend adapté à des cas d’usage complexes comme les connexions longues et les mises à jour temps réel
  • Batteries included : gRPC prend directement en charge des fonctions importantes comme l’équilibrage de charge, les retries et les timeouts
• Limites de gRPC
  • Support navigateur : la prise en charge native de gRPC dans les navigateurs reste limitée, ce qui le rend peu adapté à une communication directe client-serveur pour les applications web
  • Courbe d’apprentissage : les développeurs doivent apprendre à utiliser les protocol buffers, les définitions de services personnalisées et d’autres fonctions de gRPC, ce qui peut réduire la productivité initiale
  • Complexité du débogage : les protocol buffers ne sont pas lisibles par l’humain, ce qui rend le débogage et les tests d’API gRPC plus difficiles que pour des API JSON

Autres protocoles d’API

• MQTT : protocole de messagerie léger optimisé pour les réseaux à faible bande passante, comme l’IoT. Il permet aux clients de publier et de s’abonner à des messages via un broker, mais manque de certaines fonctions de sécurité et d’évolutivité
• AMQP : standard de messagerie d’entreprise plus robuste, garantissant une livraison fiable des messages et un routage flexible. Il peut toutefois être plus complexe et plus coûteux en overhead que des protocoles légers
• SSE : permet une communication unidirectionnelle serveur-client via HTTP ; adapté aux mises à jour en temps réel, mais dépourvu de capacités bidirectionnelles
• EDI : automatise la communication B2B en standardisant les documents électroniques comme les bons de commande et les factures, mais nécessite un coût initial élevé et une infrastructure complexe
• EDA : favorise une architecture orientée événements, où les composants réagissent aux événements, ce qui permet des systèmes temps réel évolutifs mais plus complexes à déboguer

Conclusion

• Le paysage des API continue d’évoluer à mesure que les développeurs adoptent de nouvelles architectures, de nouveaux protocoles et de nouveaux outils
• REST reste dominant grâce à sa simplicité et à son omniprésence, mais des alternatives comme GraphQL et gRPC gagnent en intérêt en répondant à des points de friction tels que l’over-fetching et les interfaces trop bavardes
• Les développeurs accordent également une importance croissante à WebHooks et WebSocket en raison des besoins en communication temps réel
• Pour de nombreux cas d’usage API courants, REST demeure une approche de base solide compte tenu de son évolutivité, de son interopérabilité et de sa facilité d’adoption. Il bénéficie aussi de la maturité de son écosystème
• Malgré cela, chaque protocole a ses avantages et ses inconvénients, et à mesure que les applications deviennent plus complexes, les développeurs élargissent intelligemment leur boîte à outils API pour y inclure des solutions spécialisées comme GraphQL et gRPC
• Plutôt qu’une solution miracle universelle, il est préférable pour les développeurs d’API de bien comprendre les forces et les faiblesses de plusieurs protocoles
• En concevant des systèmes combinant REST, WebHook, WebSocket, GraphQL et d’autres approches ayant chacune leurs propres avantages, les développeurs peuvent construire des API robustes, efficaces et maintenables
• Même si la popularité de chaque protocole continuera à fluctuer, la tendance la plus importante dans le paysage des API est l’augmentation de la diversité
• Les développeurs doivent adopter cette philosophie multi-protocole pour créer des solutions API optimales

[zerocyber]

Très sympa, merci !

[test191919]

S'il ne s'agit pas d'une tâche qui se termine par une simple action ponctuelle, les transactions ne sont-elles pas indispensables ? (Je comprends aussi le côté ironique du fait qu'on s'oriente seulement maintenant vers REST alors que c'est pourtant indispensable haha)