Les API Web expliquées simplement

L'analogie du restaurant

On voit cette analogie partout mais je pense que c'est la manière la plus facile et efficace de vraiment comprendre ce qu'est une API.

L'idée c'est d'assimiler l'API au rôle d'un serveur dans un restaurant. Le client consulte le menu (la documentation), formule une demande (la requête), le serveur la transmet en cuisine (le système qui traite l'information) et revient avec le plat commandé (la réponse). L'utilisateur n'a pas besoin de connaître les détails internes du fonctionnement : seule la garantie de recevoir le bon résultat importe.

Concrètement, c'est quoi ?

Une API (Application Programming Interface), c'est une interface qui permet à un logiciel d'en interroger un autre. En gros, c'est un contrat : "Si tu me demandes ça de cette manière, je te garantis que je te renverrai ça." Ça évite de réinventer la roue à chaque projet. On veut gérer des paiements ? On se branche sur Stripe. On veut des cartes ? Google Maps. De l'authentification ? OAuth. Tout est déjà là.

Ce que ça apporte :

• Réutiliser des fonctionnalités existantes (paiement, cartes, authentification, messagerie…)
• Connecter facilement plusieurs services au sein d'une même application
• Valoriser des services ou des données en les rendant accessibles via une API

Exemples du quotidien

Uber : L'application interroge l'API Google Maps pour le calcul d'itinéraires et utilise une API de paiement (Stripe, Apple Pay, etc.) pour traiter la transaction.

Connexion sociale : Le bouton « Se connecter avec Google » s'appuie sur une API d'authentification sécurisée qui permet à un site tiers de vérifier l'identité de l'utilisateur sans jamais connaître son mot de passe.

Météo : Les applications météo ne génèrent pas elles-mêmes les prévisions : elles interrogent des services externes via des API, comme OpenWeatherMap, qui renvoient les données en temps réel.

Comment ça communique ?

Une API web s'appuie généralement sur un schéma simple : une requête est envoyée, un traitement est effectué côté serveur, puis une réponse est retournée au client.

Les méthodes HTTP les plus courantes sont :

• GET : récupérer des données (ex: afficher la liste des utilisateurs)
• POST : créer une ressource (ex: ajouter un nouvel utilisateur)
• PUT/PATCH : modifier une ressource (ex: changer l'email d'un utilisateur)
• DELETE : supprimer une ressource (ex: supprimer le compte d'un utilisateur)

Les réponses sont souvent renvoyées au format JSON :

{
  "id": 1,
  "nom": "Dupont",
  "email": "dupont@example.com"
}

Les différents types d'API

Maintenant qu'on a vu comment ça communique, parlons un peu des architectures. Il existe plusieurs façons de concevoir une API, mais deux approches dominent (ou ont dominé) : REST et SOAP.

REST

REST (Representational State Transfer), c'est le standard actuel.

• Utilise directement HTTP
• Chaque requête est indépendante - pratique pour scaler, mais ça veut dire qu'on renvoie le contexte à chaque fois
• JSON dans 99% des cas, même si techniquement on peut utiliser un autre format

SOAP

SOAP (Simple Object Access Protocol), c'est l'ancienne école. Plus rigide, plus verbeux, mais parfois nécessaire.

• Utilise exclusivement XML (prépare-toi à des balises partout)
• Intègre nativement des mécanismes de sécurité avancés (WS-Security, etc.)
• Plus formel et plus lourd, mais adapté aux systèmes critiques (banques, assurances, grands systèmes historiques)

SOAP, franchement, sauf si on bosse dans une banque ou une grosse entreprise avec du legacy, on a peu de chances d'y toucher. REST a clairement gagné la bataille pour tout ce qui est web moderne.

Et la sécurité dans tout ça ?

Une API publique sans sécurité, c'est la porte ouverte. Du coup, la plupart des API nécessitent une authentification. Les méthodes les plus courantes :

• API Keys : une clé unique que tu passes dans ta requête. Simple mais à ne jamais exposer côté client.
• OAuth : le système derrière "Se connecter avec Google/Facebook". Plus complexe mais bien plus sécurisé pour gérer des permissions.
• JWT (JSON Web Tokens) : des tokens chiffrés qui prouvent ton identité sans renvoyer ton mot de passe à chaque fois.

Pour conclure

Les API, c'est le ciment du web. Elles permettent à tous ces services qu'on utilise quotidiennement de communiquer sans que chacun doive recoder toute la stack. (et il faut bien dire que ça nous fait gagner un temps fou)

REST domine aujourd'hui parce que c'est simple et que ça marche. SOAP existe encore dans les environnements où la sécurité et la formalisation sont critiques, mais pour un projet web classique, on part souvent directement sur du REST.

Le meilleur moyen de se lancer c'est de tester des API publiques. Lire la doc, lancer quelques requêtes avec Postman ou directement en JavaScript. On comprend 10x mieux qu'en lisant des définitions.