Ce qu'est un service web, la comparaison SOAP / REST, les principes de REST (ressources, verbes HTTP, codes de statut, sans état), le format JSON avec json_encode et json_decode, l'écriture d'une API produits en PHP et son appel depuis JavaScript avec fetch.
Souk Atlas veut une application mobile, et un transporteur de Casablanca veut consulter les commandes à livrer depuis son propre logiciel. Ni l'un ni l'autre n'a besoin de pages HTML : ils veulent les données. Un service web les leur fournit dans un format que n'importe quel programme sait lire.
L'application mobile demande GET /api/produits.php?id=9. Elle veut des données, pas une page HTML.
Une API (Application Programming Interface) est l’ensemble des opérations qu’un programme met à la disposition des autres. Quand ces opérations passent par le web, on parle d’API web ou de service web. Deux grands styles existent.
| SOAP | REST | |
|---|---|---|
| Nature | protocole normalisé | style d’architecture |
| Format | XML uniquement | JSON le plus souvent (aussi XML, CSV…) |
| Contrat | WSDL obligatoire | libre (documentation, souvent OpenAPI) |
| Verbes HTTP | presque toujours POST | GET, POST, PUT, PATCH, DELETE |
| Erreurs | élément <soap:Fault> | codes de statut HTTP |
| Poids des messages | lourd (enveloppe XML) | léger |
| Usages typiques | banque, assurance, administrations, systèmes anciens | applications mobiles, sites JavaScript, API publiques |
| Verbe | Sur /api/produits.php | Sur /api/produits.php?id=9 |
|---|---|---|
| GET | liste des produits | le produit 9 |
| POST | créer un produit | — |
| PUT / PATCH | — | remplacer / modifier le produit 9 |
| DELETE | — | supprimer le produit 9 |
Les codes les plus utilisés : 200 OK, 201 Created (après un POST), 204 No Content (après un DELETE), 400 Bad Request (JSON illisible), 401 Unauthorized (pas identifié), 403 Forbidden (pas le droit), 404 Not Found, 405 Method Not Allowed, 422 Unprocessable Content (données invalides), 500 erreur du serveur.
$p = ['id' => 9, 'nom' => 'Tapis berbère', 'prix' => 1200.0, 'en_stock' => true];
echo json_encode($p);
// {"id":9,"nom":"Tapis berb\u00e8re","prix":1200,"en_stock":true}
echo json_encode($p, JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT);
// accents gardés, une clé par ligne
$tab = json_decode('{"nom":"Savon noir","prix":30}', true); // tableau associatif
echo $tab['nom']; // Savon noir
Un tableau indexé ([0 => ..., 1 => ...]) devient une liste JSON [...], un tableau associatif devient un objet {...}. Sans le second argument true, json_decode renvoie un objet stdClass ($obj->nom).
Le squelette d’une API en PHP natif tient en quelques étapes :
Content-Type: application/json; charset=utf-8 ;$_SERVER['REQUEST_METHOD'] et l’identifiant éventuel ;json_decode(file_get_contents('php://input'), true) ;http_response_code() et json_encode().C’est le lien avec le module de programmation JavaScript : la page HTML est chargée une fois, puis fetch demande les données à l’API et met la page à jour sans la recharger.
// lire
const produits = await fetch('api/produits.php').then((r) => r.json());
// créer
const r = await fetch('api/produits.php', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ nom: 'Lanterne', categorie_id: 1, prix: 260 }),
});
if (r.status === 201) console.log('créé', await r.json());
Au comptoir, il y a des gestes standards : consulter un article, en commander un, modifier ou annuler une commande. N'importe quel client sait s'en servir sans connaître l'entrepôt. Une API REST propose ces gestes (GET, POST, PUT, DELETE) sur des ressources.
Certaines démarches exigent un formulaire très détaillé, toujours le même, avec tampons et rubriques obligatoires. C'est l'esprit de SOAP : un contrat strict (WSDL) et des messages XML complets, lourds mais très encadrés.
La page s'affichera ici.
Le navigateur demandera /api/produits.php au serveur, qui exécutera le PHP et renverra du HTML.
Consignes 0 / 4
Complétez l'API avec PUT api/produits.php?id=9 (mise à jour du prix et du stock à partir du JSON reçu) et DELETE api/produits.php?id=9. Répondez 204 sans contenu après une suppression réussie, 404 si le produit n'existe pas.
<?php if ($methode === 'PUT' && $id) { $d = json_decode(file_get_contents('php://input'), true) ?? []; $req = $pdo->prepare('UPDATE produits SET prix = :prix, stock = :stock WHERE id = :id'); $req->execute(['prix' => $d['prix'] ?? 0, 'stock' => $d['stock'] ?? 0, 'id' => $id]); $req = $pdo->prepare('SELECT id, nom, prix, stock FROM produits WHERE id = ?'); $req->execute([$id]); $p = $req->fetch(); $p ? repondre(200, $p) : repondre(404, ['erreur' => 'Produit introuvable']); } if ($methode === 'DELETE' && $id) { $req = $pdo->prepare('DELETE FROM produits WHERE id = ?'); $req->execute([$id]); if ($req->rowCount() === 0) repondre(404, ['erreur' => 'Produit introuvable']); http_response_code(204); exit; }
Un autre script PHP doit lire le produit n° 9 de l'API et afficher son nom. Utilisez file_get_contents sur l'URL de l'API, puis json_decode.
<?php $json = file_get_contents('http://localhost/api/produits.php?id=9'); $produit = json_decode($json, true); // true : tableau associatif plutôt qu'objet if (json_last_error() !== JSON_ERROR_NONE) { exit('Réponse illisible'); } echo htmlspecialchars($produit['nom']); // Tapis berbère
Pour chaque situation, dites quel style vous choisiriez et pourquoi : (a) une application mobile qui affiche le catalogue ; (b) la connexion à un service bancaire existant qui fournit un fichier WSDL ; (c) un site JavaScript qui met à jour le panier sans recharger la page.
(a) REST + JSON : léger, lisible, facile à consommer depuis le mobile, et les GET se mettent en cache. (b) SOAP : le service impose déjà un contrat WSDL ; la classe SoapClient de PHP génère les appels à partir de ce contrat. (c) REST + JSON : fetch() en JavaScript lit directement le JSON, sans enveloppe XML à analyser.