Un web service permet à deux logiciels d'échanger des données par HTTP : une boutique qui envoie ses commandes à un ERP, une application mobile qui lit un catalogue, un transporteur qui renvoie un numéro de suivi. En PHP, on en crée un aujourd'hui sous forme d'API REST qui répond en JSON. SOAP existe toujours, mais il est réservé à des cas précis.
Le principe d'une API REST
Chaque ressource a une adresse, et la méthode HTTP dit ce que l'on veut en faire :
| Méthode |
Adresse |
Action |
Réponse attendue |
GET |
/api/produits |
lister |
200 et la liste |
GET |
/api/produits/12 |
lire un produit |
200, ou 404 s'il n'existe pas |
POST |
/api/produits |
créer |
201 et le produit créé |
PUT ou PATCH |
/api/produits/12 |
modifier |
200 |
DELETE |
/api/produits/12 |
supprimer |
204 sans contenu |
Les codes de réponse font partie du contrat : le logiciel qui appelle l'API s'en sert pour savoir si tout s'est bien passé, sans lire le texte.
Une API REST minimale en PHP
Un seul fichier api.php, appelé par toutes les adresses /api/… grâce à une règle de réécriture du serveur.
<?php
declare(strict_types=1);
header('Content-Type: application/json; charset=utf-8');
function repondre(int $code, mixed $donnees = null): never
{
http_response_code($code);
if ($donnees !== null) {
echo json_encode($donnees, JSON_UNESCAPED_UNICODE | JSON_THROW_ON_ERROR);
}
exit;
}
// Authentification par clé, transmise dans l'en-tête Authorization: Bearer <clé>
$cle = getenv('API_CLE') ?: '';
$recue = preg_replace('/^Bearer\s+/i', '', $_SERVER['HTTP_AUTHORIZATION'] ?? '');
if ($cle === '' || !hash_equals($cle, $recue)) {
repondre(401, ['erreur' => 'Clé API absente ou invalide']);
}
$pdo = new PDO(getenv('BDD_DSN'), getenv('BDD_USER'), getenv('BDD_PASS'), [
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC,
]);
$methode = $_SERVER['REQUEST_METHOD'];
$chemin = trim(parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH), '/');
if (preg_match('#^api/produits/(\d+)$#', $chemin, $m)) {
if ($methode !== 'GET') {
header('Allow: GET');
repondre(405, ['erreur' => 'Méthode non autorisée']);
}
$req = $pdo->prepare('SELECT id, nom, prix FROM produits WHERE id = ?');
$req->execute([(int) $m[1]]);
$produit = $req->fetch() ?: repondre(404, ['erreur' => 'Produit introuvable']);
repondre(200, $produit);
}
if ($chemin === 'api/produits' && $methode === 'POST') {
$corps = json_decode(file_get_contents('php://input'), true);
if (!is_array($corps) || empty($corps['nom']) || !is_numeric($corps['prix'] ?? null)) {
repondre(422, ['erreur' => 'Champs attendus : nom, prix']);
}
$req = $pdo->prepare('INSERT INTO produits (nom, prix) VALUES (?, ?)');
$req->execute([$corps['nom'], $corps['prix']]);
repondre(201, ['id' => (int) $pdo->lastInsertId()] + $corps);
}
repondre(404, ['erreur' => 'Ressource inconnue']);
Pour le tester en ligne de commande :
curl -H "Authorization: Bearer ma-cle" https://exemple.fr/api/produits/12
curl -X POST -H "Authorization: Bearer ma-cle" \
-H "Content-Type: application/json" \
-d '{"nom":"Pelote laine","prix":7.5}' \
https://exemple.fr/api/produits
Si la clé est toujours refusée sous Apache, c'est souvent que l'en-tête Authorization n'arrive pas jusqu'à PHP (PHP-FPM ou CGI) : ajoutez CGIPassAuth On dans le .htaccess.
Ce code tient en une page, mais il contient déjà l'essentiel : une réponse JSON, des codes HTTP justes, une clé vérifiée, des requêtes préparées.
Sécuriser un web service
Une API est une porte d'entrée directe vers vos données. Les points à ne jamais négliger :
- HTTPS obligatoire : sans lui, la clé circule en clair.
- Clé hors du code : dans une variable d'environnement ou un fichier de configuration hors du dossier public, jamais dans un dépôt Git. Comparez-la avec
hash_equals(), pas avec ==.
- Requêtes préparées pour tout ce qui vient de l'appelant : c'est la protection contre l'injection SQL.
- Validation des entrées : types, longueurs, valeurs autorisées. Répondez
422 à une donnée invalide plutôt que de l'enregistrer.
- Droits minimaux : une clé par logiciel appelant, limitée aux ressources et aux méthodes dont il a besoin.
- Limite de débit et journal des appels, pour repérer un abus ou un logiciel qui boucle.
- CORS : n'ajoutez
Access-Control-Allow-Origin que si l'API doit être appelée depuis un navigateur, et seulement pour les domaines concernés.
REST ou SOAP ?
SOAP, très répandu dans les années 2000, échange des messages XML décrits par un contrat WSDL. PHP le gère toujours avec l'extension soap (SoapServer, SoapClient).
Vous le croiserez surtout côté client : certains transporteurs, éditeurs d'ERP, banques ou administrations n'exposent encore que du SOAP. Pour créer un nouveau web service, REST et JSON sont plus simples à écrire, à tester et à documenter.
Quand passer à un framework
Le fichier ci-dessus convient à quelques routes. Au-delà, un framework évite de réinventer le routage, la validation, l'authentification et la documentation. Avec Symfony et API Platform, une entité déclarée devient une API complète : routes, pagination, filtres, validation, et documentation OpenAPI générée automatiquement. Slim ou Laravel sont d'autres options courantes.
Le webservice intégré à PrestaShop
Avant d'écrire une API pour une boutique PrestaShop, vérifiez si celle qui est fournie suffit. PrestaShop intègre depuis longtemps un webservice qui expose produits, stocks, clients, commandes, catégories et bien d'autres ressources.
- Dans le back-office : Paramètres avancés › Webservice, activez le service.
- Créez une clé, et cochez uniquement les ressources et les méthodes (
GET, POST, PUT, DELETE) dont le logiciel appelant a besoin.
- Appelez l'API à l'adresse
/api/ de la boutique, la clé servant d'identifiant HTTP :
curl -u "VOTRE_CLE:" "https://boutique.fr/api/products/12?output_format=JSON"
Le webservice répond en XML par défaut, en JSON avec output_format=JSON. Il repose sur une règle de réécriture : sous Apache, le .htaccess de PrestaShop s'en charge ; sous nginx, il faut une règle qui envoie /api/ vers webservice/dispatcher.php.
PrestaShop 9 ajoute une nouvelle API d'administration, construite sur API Platform et sécurisée par OAuth2. Pour un nouveau développement sur PrestaShop 9, elle mérite d'être étudiée avant l'ancien webservice.
Quand ni l'un ni l'autre ne couvre le besoin (un calcul métier, un format imposé par un partenaire), on crée un module qui expose ses propres routes, plutôt que de modifier le cœur de PrestaShop.
Relier votre boutique à un autre logiciel ?
ERP, logiciel de caisse, transporteur, marketplace : nous développons les connecteurs et les modules qui font circuler les données entre votre boutique et vos outils, sans saisie en double. Notre agence PrestaShop · Migration vers PrestaShop 9.