Définition
Une API REST (Representational State Transfer) est un style d’architecture logicielle qui expose des ressources via le protocole HTTP. Dans l’écosystème DTC et e-commerce, elle permet à des systèmes hétérogènes — boutique Shopify, ERP, WMS, plateformes publicitaires, outils de logistique — d’échanger des données de manière standardisée, sans intervention manuelle.
Concrètement, une API REST fonctionne comme un guichet unique numérique : chaque ressource (commande, stock, campagne) possède une URL unique, et les opérations s’effectuent avec les verbes HTTP standards (GET, POST, PUT, PATCH, DELETE). Le serveur renvoie généralement du JSON, format léger et lisible par la plupart des langages.
Pour un marchand DTC, maîtriser REST signifie : synchroniser les commandes en temps réel, éviter les ruptures de stock, ajuster les budgets publicitaires automatiquement, et connecter des outils sans dépendre d’un développeur interne à plein temps.
Analogie
Imaginez un entrepôt logistique avec plusieurs portes d’entrée :
- GET = consulter l’état d’une palette sans y toucher.
- POST = déposer une nouvelle palette (créer une commande).
- PUT = remplacer intégralement une palette (mise à jour complète d’une fiche produit).
- PATCH = modifier une seule étiquette sur la palette (changer le prix).
- DELETE = retirer la palette du stock.
Chaque porte correspond à une URL. Le transporteur (votre application) ne se soucie pas de l’organisation interne de l’entrepôt : il suit les règles HTTP et obtient une réponse standardisée. C’est cette séparation client/serveur qui rend REST si robuste pour le DTC.
Formule
Le principe REST repose sur une relation requête/réponse sans état :
Requête HTTP = Méthode + URL + En-têtes + Corps (optionnel) Réponse HTTP = Code statut + En-têtes + Corps (JSON/XML)
Exemple concret de synchronisation de stock :
PATCH /api/v1/inventory/SKU-12345
Content-Type: application/json
Authorization: Bearer <token>
{ "quantity": 87 }
Réponse attendue :
200 OK
{ "sku": "SKU-12345", "quantity": 87, "updated_at": "2025-01-15T10:32:00Z" }
Codes de statut à connaître :
- 200 : succès
- 201 : ressource créée
- 400 : requête invalide
- 401 : authentification manquante
- 429 : trop de requêtes (rate limiting)
- 500 : erreur serveur
Un rate limit typique en DTC : 2 000 requêtes par minute pour Shopify Plus, 100 requêtes par seconde pour Meta Marketing API, 10 requêtes par seconde pour Amazon SP-API.
Tableau comparatif
| Critère | REST API | GraphQL | SOAP | Webhook |
|---|---|---|---|---|
| Format | JSON (majoritaire) | JSON | XML | JSON |
| Verbes | HTTP standards | Query/Mutation | Opérations | Push serveur |
| Temps réel | Non (polling) | Non (sauf subscriptions) | Non | Oui |
| Over-fetching | Fréquent | Évité | Fréquent | N/A |
| Idéal DTC | Sync commandes, stock | Dashboards complexes | ERP legacy | Notifications paiement |
| Courbe d’apprentissage | Faible | Moyenne | Élevée | Faible |
| Coût serveur | Modéré | Modéré | Élevé | Faible |
Applications concrètes en DTC
1. Synchronisation des commandes : une commande passée sur Shopify déclenche un POST vers l’ERP, qui renvoie un 201 avec l’ID interne. Délai cible : < 3 secondes.
2. Mise à jour des stocks multi-canal : le WMS pousse un PATCH vers la boutique et vers Amazon. Sans cela, risque de survente estimé à 8 % du CA pour un marchand multi-canal.
3. Pilotage publicitaire : récupération des performances Meta/Google via GET, puis ajustement automatique des budgets. Une marque DTC économise en moyenne 12 à 18 % de son spend publicitaire.
4. Suivi logistique : interrogation des transporteurs (Colissimo, DHL, UPS) pour mettre à jour le statut de livraison côté client.
5. Service client : connexion de Zendesk ou Gorgias à l’API commande pour afficher l’historique en temps réel.
Erreurs fréquentes
- Confondre REST et HTTP : REST est un style, HTTP est le protocole. Toute API HTTP n’est pas REST.
- Ignorer le rate limiting : envoyer 5 000 requêtes sans backoff déclenche un 429 et bloque votre intégration.
- Négliger l’authentification : stocker un token en clair dans le front-end expose vos données. Utilisez OAuth 2.0 ou des clés côté serveur.
- Oublier l’idempotence : un POST rejoué peut créer un doublon de commande. Utilisez un Idempotency-Key.
- Sous-estimer la latence : une API mal conçue peut ajouter 500 ms à 2 s par appel. Pour 10 000 commandes/jour, cela devient critique.
- Ne pas versionner : passer de /v1/ à /v2/ sans préavis casse les intégrations partenaires.
Termes liés
- Endpoint : URL d’accès à une ressource.
- Payload : corps de la requête ou de la réponse.
- Token Bearer : jeton d’authentification.
- Webhook : notification push complémentaire à REST.
- GraphQL : alternative flexible à REST.
- Rate limiting : limitation du nombre d’appels.
- Idempotence : propriété d’une requête rejouable sans effet secondaire.
- API Gateway : point d’entrée unique pour sécuriser et router les appels.
- OAuth 2.0 : standard d’autorisation déléguée.
- Middleware : couche intermédiaire de transformation des données.
