Expertise PrestaShop

Conseils techniques e-commerce et PrestaShop

Une question ? Contactez Les Vikings

API SOAP vs REST : différences, sécurité et cas d’usage

Analyse pragmatique des choix SOAP vs REST pour l’e‑commerce : impacts sur performance, sécurité et maintenance, avec conseils (adapter, gateway, anti‑corruption) pour PrestaShop.

Kévin DECQ-CAILLET

|

Écran d'ordinateur avec comparaison visuelle des API SOAP et REST.

Table des matières :

  1. SOAP vs REST : le contrat (WSDL) contre les ressources HTTP
  2. Payloads, erreurs, versioning : ce que ça change réellement en production
  3. Sécurité : WS-Security n’est pas une solution miracle, OAuth non plus
  4. Cas d’usage e‑commerce (PrestaShop, ERP, marketplaces) : choisir sans dogme
  5. Matrice de choix et patterns de migration (adapter, gateway, anti‑corruption layer)

SOAP vs REST : le contrat (WSDL) contre les ressources HTTP

Comparer une API SOAP à une API REST n’a d’intérêt que si on parle de couplage, de contrat, et de propriétés opérationnelles (cache, observabilité, sécurité), pas de “modernité”. SOAP est un protocole de messagerie standardisé autour d’enveloppes XML (Envelope/Header/Body) et, dans la plupart des SI, d’un contrat WSDL (Web Services Description Language) décrivant opérations, types et endpoints. La définition historique de SOAP est explicite : le W3C décrit SOAP comme « a lightweight protocol for exchange of information in a decentralized, distributed environment » (W3C, SOAP 1.1 Note, 2000, W3C SOAP 1.1 Note).

REST, à l’inverse, n’est pas un protocole. C’est un style d’architecture qui s’appuie très bien sur HTTP quand on respecte ses contraintes (ressources adressables, interface uniforme, stateless, cacheable…). Dans sa thèse, Roy Fielding positionne clairement l’objectif : « REST is an architectural style for distributed hypermedia systems » (Fielding, 2000, Fielding, thèse). En pratique, “REST” sur le web veut dire : des ressources (URI), des méthodes HTTP sémantiques (GET/POST/PUT/PATCH/DELETE), et des représentations (JSON, XML…) avec négociation de contenu.

La différence “contrat vs ressources” se voit vite dans l’outillage :

  • SOAP/WSDL (contract-first) : génération de stubs côté client/serveur, validation stricte via XSD, typage fort, mais aussi une dépendance lourde à la structure exacte du contrat (namespaces, types, ordonnancement). Une simple modification de type peut forcer une régénération et une montée de version côté clients.
  • REST/OpenAPI (resource-first ou design-first) : documentation et génération possibles (SDK, tests, mocks), mais le contrat est souvent plus tolérant (schémas JSON, contraintes partiellement exprimables) et dépend de conventions HTTP (statuts, headers) autant que du payload.

Dans un projet e-commerce, l’impact est immédiat : SOAP te force souvent dans une approche contract-first (WSDL + XSD, génération de clients/serveurs, validation stricte), ce qui réduit l’ambiguïté mais augmente la rigidité et le coût de maintenance. REST, quand il est bien conçu, favorise une approche resource-first et une intégration plus naturelle avec l’écosystème HTTP (reverse proxies, caches, API gateways, outils de tracing).

Mini-scenario (très courant en SI retail) : un ERP impose un WSDL “commande + facture + stock” avec des types XSD très contraints. Si tu fais consommer ce SOAP directement par plusieurs briques (modules PrestaShop, workers, BI), tu propages le couplage WSDL partout. À l’inverse, si tu exposes un REST interne “/orders, /invoices, /stocks” en modèle canonique et tu gardes le SOAP seulement dans un adaptateur, tu limites le blast radius quand l’ERP publie une V2.

Pour cadrer la partie HTTP (verbes, statuts, headers) et éviter le “REST-RPC”, garde sous la main la base : Endpoint API : définition, méthodes HTTP et bonnes pratiques REST.

Payloads, erreurs, versioning : ce que ça change réellement en production

Sur le fil, SOAP repose sur XML avec un enveloppement systématique, et souvent des schémas XSD lourds. C’est robuste pour des payloads complexes (types imbriqués, contraintes), mais coûteux en taille et en CPU (parsing XML, namespaces, canonicalisation). Une règle empirique fréquemment observée en prod : à structure équivalente, un XML SOAP est souvent sensiblement plus volumineux qu’un JSON “plat” ; en HTTP/2 + gzip/brotli l’écart diminue, mais le coût de sérialisation/désérialisation reste. En PHP, l’extension ext-soap et/ou des stacks basées sur DOM/XMLReader peuvent devenir le goulot sur des gros volumes (imports, sync commandes), surtout si tu fais de la validation XSD à chaque appel.

Deux points “production” qu’on sous-estime souvent :

  1. Bulk vs temps réel
  • SOAP (et XML) n’est pas “incapable” de faire du bulk, mais tu peux te retrouver avec des payloads énormes, difficiles à rejouer et à tracer.
  • REST n’est pas automatiquement “léger” : si tu fais du N+1 (ex : 1 appel par ligne de commande), tu perds tout l’avantage. La solution est souvent un design d’endpoint adapté : POST /orders:batch (ou un job asynchrone) plutôt que 1 POST par entité.
  1. Observabilité
  • En SOAP, on voit souvent passer des corrélations via des headers WS-* (ex. WS-Addressing) ou des conventions maison.
  • En REST/HTTP, tu peux standardiser via traceparent (W3C Trace Context), X-Request-Id, et des logs structurés plus facilement alignés avec API gateways / reverse proxies.

Côté REST, la réalité est moins “magique” qu’on le vend : beaucoup d’APIs REST finissent en RPC déguisé (/doSomething), et les erreurs deviennent inconsistantes (tantôt 200 avec un JSON d’erreur, tantôt 500). La différence, c’est qu’HTTP apporte un cadre normalisé : statuts, headers, cache-control, idempotence. Le RFC 9110 rappelle un point qui a des conséquences de design : « HTTP is a stateless request/response protocol » (RFC 9110, 2022, RFC 9110). Si tu gardes cet invariant, tu simplifies la scalabilité horizontale (pas d’état serveur par session), ce qui compte dès que tu passes derrière un load balancer.

Erreurs : SOAP Fault vs statuts HTTP “propres”

En SOAP, l’erreur applicative est typiquement encapsulée dans un Fault (même si le transport HTTP peut aussi porter un statut). En REST, la bonne pratique est de tirer profit des statuts HTTP et de fournir un corps d’erreur stable. Un format très utilisé est “Problem Details” (RFC 7807) : ça donne un schéma d’erreur prédictible (type, title, status, detail, instance), utile pour les clients et pour les dashboards.

Exemple minimal :

<!-- SOAP Fault (simplifié) -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <soap:Fault>
      <faultcode>soap:Client</faultcode>
      <faultstring>SKU inconnu</faultstring>
    </soap:Fault>
  </soap:Body>
</soap:Envelope>
# REST + Problem Details (exemple)
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/problem+json

{
  "type": "https://example.com/problems/unknown-sku",
  "title": "SKU inconnu",
  "status": 422,
  "detail": "La référence ABC n’existe pas dans le catalogue.",
  "instance": "/api/orders/attempts/9f2c"
}

Versioning : éviter le “big bang”

Le versioning est un vrai sujet. Avec SOAP, versionner un WSDL/XSD est douloureux mais formalisé : tu peux publier ServiceV1, ServiceV2, avec des namespaces distincts, et les clients générés suivent… au prix d’une coexistence parfois longue (et d’un support multi-versions). En REST, tu as plusieurs stratégies (version dans l’URL /v1/, dans un header Accept: application/vnd..., ou par évolution additive).

La stratégie la moins casse-gueule sur un écosystème hétérogène (ERP, WMS, scripts maison, apps mobiles), c’est généralement :

  • évolution additive (ajouter champs/ressources sans casser),
  • dépréciation documentée (dates, impact, endpoints concernés),
  • tests de contrat et validation OpenAPI côté CI (mocks + tests d’intégration).

Oui, OpenAPI n’est pas WSDL, mais ça reste une base solide pour générer des SDK, automatiser des tests, et vérifier que tes changements ne cassent pas des clients.

Voici un contraste concret (même intention fonctionnelle, coût différent) :

<!-- SOAP : création de commande (très simplifié) -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header/>
  <soap:Body>
    <CreateOrder>
      <CustomerId>123</CustomerId>
      <Lines>
        <Line><Sku>ABC</Sku><Qty>2</Qty></Line>
      </Lines>
    </CreateOrder>
  </soap:Body>
</soap:Envelope>
# REST : création de commande
POST /api/orders HTTP/1.1
Content-Type: application/json

{"customerId":123,"lines":[{"sku":"ABC","qty":2}]}

À l’échelle production, la différence se joue surtout sur : idempotence (réessais), timeouts, et rejouabilité. Typiquement, pour un POST /orders, beaucoup d’équipes ajoutent une clé d’idempotence (header Idempotency-Key) afin d’éviter les doublons quand un reverse proxy ou un client réessaie après un timeout.

Sécurité : WS-Security n’est pas une solution miracle, OAuth non plus

La sécurité est l’angle où SOAP est souvent mal compris. Le point fort de SOAP, c’est la possibilité de faire de la sécurité au niveau message (signatures XML, chiffrement XML, tokens SAML) via WS-Security. Ça répond à des scénarios spécifiques : messages qui transitent via des intermédiaires, exigences de non-répudiation, besoin de signer uniquement une partie du payload, etc. Dans certains environnements “enterprise” (B2B, interop historique), c’est encore un requirement contractuel.

Le revers est brutal : la sécurité XML est complexe et a une longue histoire de vulnérabilités et de mauvaises implémentations (signature wrapping, canonicalisation, confusion d’IDs). Ajoute à ça les risques XML classiques : XXE (XML External Entity), bombes XML, SSRF via entités externes si le parser n’est pas durci. En PHP, ça veut dire : proscrire les parseurs permissifs, désactiver la résolution d’entités externes, limiter la taille/complexité, et idéalement streamer (XMLReader) plutôt que charger un DOM complet. Si tu n’es pas en mesure d’auditer la stack SOAP (client et serveur) et de tenir à jour les dépendances, WS-Security peut devenir un faux sentiment de sécurité.

En REST, l’approche la plus réaliste en 2026 reste : TLS partout + authN/authZ standard (OAuth 2.0 / OIDC, JWT ou tokens opaques) + contrôles compensatoires (rate limiting, WAF, validation stricte, logs structurés). C’est précisément là où les incidents arrivent : l’OWASP insiste sur l’autorisation comme source principale de failles ; l’édition 2023 rappelle que BOLA (Broken Object Level Authorization) est l’une des catégories les plus critiques (OWASP, API Security Top 10, OWASP API Security).

Dans un contexte France/UE, pense aussi “sécurité + conformité” : au-delà de l’authentification, la protection des données (RGPD) rend indispensables la minimisation (ne pas exposer plus de champs que nécessaire), la traçabilité (qui a accédé à quoi, quand), et une politique claire de rétention des logs.

Checklist pragmatique (REST comme SOAP) :

  • TLS : versions et suites de chiffrement à jour, désactivation des configurations faibles, supervision des expirations de certificats.
  • AuthZ : tests systématiques de contrôle d’accès (IDOR/BOLA), scopes minimaux, séparation “lecture/écriture”, et vérification côté serveur (jamais “fait confiance au client”).
  • Validation : schéma + contraintes métiers (ex : quantité > 0), protection contre l’over-posting (champs inattendus).
  • Protection volumétrique : quotas, rate limiting, timeouts cohérents, circuit breaker sur les dépendances.
  • Journalisation : logs structurés (sans données sensibles), identifiant de corrélation, et alerting sur taux d’erreur / pics.

Pour l’implémentation concrète : limitation de débit, rotation des secrets, scopes minimaux, et surtout tests d’accès (IDOR). Pour aller plus loin côté durcissement applicatif, tu peux chaîner avec :

Cas d’usage e‑commerce (PrestaShop, ERP, marketplaces) : choisir sans dogme

En e-commerce, le “bon” choix dépend rarement d’une préférence d’équipe, mais d’un parc applicatif existant. SOAP reste courant côté ERP historiques, transporteurs ou EDI modernisé (où SOAP est une façade sur des systèmes plus anciens). Si ton intégration impose un WSDL validé contractuellement (types, contraintes, numérotation de versions), partir sur SOAP peut réduire les ambiguïtés… à condition d’accepter le coût d’exploitation (outillage, observabilité, durcissement XML).

Une façon simple de raisonner est de partir de tes flux e-commerce typiques et de leur “nature” :

Flux Contraintes fréquentes Souvent mieux en… Pourquoi
Création de commande cohérence, idempotence, audit REST (synchrone) + events HTTP statuts + retries propres + traçabilité + webhooks
Mise à jour stock volumétrie, rafales REST batch / async évite N+1, meilleure résilience
Tarifs / promos règles complexes dépend si contrat tiers strict : SOAP ; sinon REST + schéma clair
Facturation / conformité non-répudiation, signature SOAP + WS-Security (cas spécifiques) signature au niveau message peut être un requirement

Côté PrestaShop, il faut distinguer deux réalités. Le Webservice PrestaShop “historique” est souvent qualifié de REST, mais il est surtout HTTP + ressources avec un format largement XML (et auth par clé), et ses limites sont connues dès qu’on sort du CRUD basique ou qu’on veut des performances propres sur gros volumes. Pour cadrer précisément ce que fait le core (et ce qu’il ne fait pas), lis :

Depuis PrestaShop 9, l’API d’administration part sur des bases plus “modernes” (API Platform, OAuth, endpoints plus structurés), ce qui colle mieux aux architectures d’intégration actuelles (portails, headless, microservices). Référence utile : API d’administration PrestaShop 9 : OAuth, API Platform v3, endpoints CQRS.

Cas concret côté marketplaces : la plupart imposent des quotas et des règles de retry strictes. Sur ce terrain, le style REST (ou “HTTP API”) est souvent plus facile à opérer, parce que tu peux standardiser les stratégies 429 (retry-after), les backoffs, et la mise en cache (GET cacheable) via ton gateway/proxy.

Si ton besoin est un pipeline de synchronisation (catalogue, stocks, commandes) avec supervision et reprise, un modèle REST + webhooks/queues est généralement plus stable qu’un SOAP synchrone ; exemple d’approche “API-first” : Import catalogue PrestaShop : pipeline API-first automatisé et supervisé.

Enfin, pour les projets headless ou composables, REST n’est qu’une option parmi d’autres (GraphQL, gRPC). Mais dans un SI e-commerce, REST reste souvent le plus simple à opérer (API gateway, caches, CDN, outillage). Si tu es dans cette trajectoire, rapproche aussi : Commerce headless : plateforme microservices et API REST/GraphQL scalable.

Matrice de choix et patterns de migration (adapter, gateway, anti‑corruption layer)

Pour décider vite entre API SOAP vs REST, la matrice utile est opérationnelle, pas idéologique : (1) as-tu besoin d’un contrat strict imposé par des tiers ? (2) as-tu besoin de message-level security (signature/chiffrement au niveau XML) ? (3) quelle est la capacité de ton équipe à maintenir une stack SOAP durcie ? Si tu coches (1)+(2), SOAP peut être rationnel. Si tu coches surtout (scalabilité, cache, intégration web/mobile, DX), REST est généralement plus rentable, avec un contrat OpenAPI et une stratégie de versioning additive.

Une matrice “terrain” (à adapter) :

  • SOAP recommandé si : WSDL imposé, XSD très contraints, exigences de signature/chiffrement au niveau message, clients outillés “enterprise” qui consomment déjà SOAP, besoin de contrats figés et formels.
  • REST recommandé si : forte intégration web/mobile, besoin de cache et d’edge (CDN, reverse proxy), volumétrie variable, exigences d’observabilité (tracing), intégrations nombreuses et hétérogènes, time-to-market important.
  • Hybride si : legacy SOAP côté ERP + écosystème moderne côté e-commerce → adapter obligatoire.

Quand tu dois faire cohabiter les deux (cas le plus fréquent), ne propage pas la complexité dans tout le SI : pose un anti-corruption layer. Typiquement : un service “adapter” qui parle SOAP vers l’ERP, et expose REST (ou événements) vers le reste. Ça t’évite de lier tes modules PrestaShop, tes workers, ou ton portail client à WSDL/XSD.

Bon pattern d’implémentation (simple et efficace) :

  1. Adapter SOAP (ingress/egress) : gère WSDL, WS-Security si nécessaire, et traduit en modèle canonique.
  2. API REST interne : stable, versioning additif, erreurs homogènes, authZ unifiée.
  3. Asynchrone quand pertinent : files/queues pour les flux bulk (stocks, prix), et webhooks pour les événements (commande créée, paiement validé).

Sur des architectures à trafic variable, tu peux encapsuler ça derrière un reverse proxy/API gateway (mTLS interne, quotas, circuit breakers). Si ton infra est déjà orientée proxy/edge, les patterns de rate limiting et de terminaison TLS décrits ici s’appliquent aussi : Configurer HAProxy comme reverse proxy : TLS, limitation de débit et supervision.

La migration (SOAP → REST ou REST → SOAP) se gère comme un chantier de compatibilité : tests contractuels, double-run sur une période, métriques de non-régression (taux d’erreur, latence P95, volumes), et plan de rollback. Concrètement, une approche qui marche bien est le strangler pattern : tu gardes l’ancien endpoint en place, tu routes progressivement vers la nouvelle implémentation (par client, par pays, par type de flux), et tu observes.

Ne sous-estime pas la partie “ops” : rotation de secrets, logs structurés, corrélation (trace-id), et environnements de pré-production réalistes. Si ton intégration touche PrestaShop (modules, overrides, webservice), cale la méthodologie de changement sur un process strict (sauvegardes, pré-prod, jeux de tests) : Mise à jour PrestaShop : checklist sauvegarde, pré-production et tests et, pour le day-2 quand ça casse, Mise à jour PrestaShop ratée : diagnostiquer et réparer rapidement.

Au final, SOAP n’est pas “obsolète”, REST n’est pas “par défaut”. SOAP est un choix acceptable quand le contrat et la sécurité au niveau message sont des contraintes réelles. REST est un choix robuste quand tu veux maximiser l’effet de levier de l’écosystème HTTP (caches, proxies, tooling, observabilité) et garder une courbe d’exploitation raisonnable. Si tu dois trancher pour une intégration PrestaShop en 2026 (PrestaShop 8.x/9.x, PHP 8.2/8.3), privilégie une API REST correctement spécifiée (OpenAPI), sécurisée (OAuth2/OIDC, scopes), et opérable (quotas, logs, traces) — et ne garde SOAP que là où il est imposé, isolé derrière un adaptateur.

À lire aussi