Aller au contenu

Les API WEB et les autres

Contexte

En 2025, les API REST/JSON ont toujours le vent en poupe. Toutefois, la mode évolue au niveau des API WEB s'appuyant sur le protocole HTTP (REST/JSON vs WebSocket vs GraphQL vs gRPC). Aussi, il semble intéressant de prendre du recul, de mesurer les limites des API exploitant le réseau, et de constater que différents types d'API coexistent et se complètent.

Quelques types d'API

Les bibliothèques de programmation

C'est le type d'API qui offre la plus grande richesse fonctionnelle et la plus grande liberté d'utilisation qui sera toujours à la base de l'édifice en présence d'une application en ligne de commande, d'un service ou d'une API WEB.

Toutefois :

  • Une bibliothèque est liée à un langage de programmation (bien qu'il soit possible de faire des "bindings" pour appeler par exemple en Python du code écrit en C++).
  • Les clients doivent avoir des compétences en programmation.
  • Les clients devront gérer les mises à jour avec plus ou moins de facilité en fonction de :
    • La qualité du packaging et l'utilisation d'un système de gestion des dépendances (apt-get upgrade, pip install -r requirements.txt, npm install,...)
    • La fréquence des versions majeures s'accompagnant souvent de changements cassants.
  • Mettre à disposition proprement une bibliothèque a un coût variable en fonction du langage utilisé et des systèmes cibles.

Les API exposées sous forme de services

Nous trouvons plusieurs systèmes mettant à disposition des API sous forme de services en réseau via des protocoles au niveau TCP ou UDP :

  • Les bases de données (PostgreSQL, MongoDB, Redis,...)
  • Les serveurs SMTP pour l'envoi de mail
  • Les serveurs DNS pour la résolution de nom
  • ...

Par rapport aux bibliothèques, nous noterons que :

  • Les mises à jour des services sont centralisées
  • Les clients peuvent être écrits dans plusieurs langages

Par rapport aux API WEB ci-après, nous noterons que :

  • Les protocoles seront très divers en fonction des services.
  • Cette hétérogénéïté se traduira par la multiplication des clients (un client par service ou type de service)

Les API WEB exposées en HTTP

Nous trouvons plusieurs types d'API WEB exposées à l'aide du protocole HTTP avec des évolutions qui semblent se faire en parallèle des évolutions sur les formats et besoins :

  • SOAP (1999) a eu le vent en poupe quand le format XML (1998) et les schémas XSD (2001) étaient à la mode.
  • SOAP a progressivement cédé du terrain au profit des API REST (2000) exploitant au choix les formats XML ou JSON.
  • Les API REST JSON/XML ont progressivement abandonné le format XML pour travailler exclusivement avec le format JSON.
  • Les WebSocket (2011) ont été créées pour répondre au besoin de communication bidirectionnelle en temps réel.
  • Nous trouvons désormais des API GraphQL (2012) visant à donner plus de souplesse dans l'exploitation des propriétés et relations que les API REST/JSON classiques au niveau de GitHub, GitLab,...
  • Le format Protocol Buffer gagne du terrain (Vector tiles, format PBF d'OSM,...) et gRPC commence à se démocratiser.
  • Un approche telle gRPC qui combine HTTP/2 et Protocol Buffer risque de détrôner les API REST/JSON pour les applications échangeant des volumes de données importants.

Quelques remarques sur les API

Une API HTTP s'accompagne souvent d'un client CLI

  • L'exécutable docker est client de l'API docker (elle est exposée par défaut via une socket linux /var/run/docker.sock mais peut être exposée en HTTPS)
  • L'exécutable kubectl est client de l'API Kubernetes

Une API HTTP peut s'appuyer en coulisse sur une application CLI

La mise en oeuvre d'une fonctionnalité d'import de données en base via une API HTTP peut par exemple être traitée en coulisse par un appel à :

  • clamav pour contrôler l'absence de virus dans un téléversement d'une archive.
  • unzip, tar ou gunzip pour décompresser l'archive.
  • ogr2ogr de GDAL pour charger les données décompressées en base.

Une application CLI peut produire des résultats formatés en JSON

Appeler une application en ligne de commande et devoir "parser" les résultats avec awk ou autres joyeusetés est pénible.

Toutefois, la vie devient plus douce quand l'application en ligne de commande est capable de produire des résultats dans un format exploitable tels CSV, JSON ou YAML.

A titre d'exemple, la commande "ip" met à disposition une telle option. Il est donc possible de traiter la sortie avec jq comme suit pour récupérer la liste des interfaces réseaux :

ip --json address | jq -r '.[].ifname'

Nous retrouvons ce même principe avec :

Une approche complète est possible

Pour une fonctionnalité, il est possible de mettre à disposition une bibliothèque, une application en ligne de commande et une API WEB!

Ressources

Généralité

Catalogue d'API

Développement d'API REST/JSON

Sécuriser les API REST

Pour les API CLI

  • clig.dev - Command Line Interface Guidelines donne d'autres bonnes pratiques pour la construction d'application en ligne de commande dont la mise à disposition d'une option --json pour spécifier le format de la sortie.