Cas pratiques SOAP/REST

On vous demande d’appeler un service REST simple renvoyant une liste de clients au format JSON via l’endpoint /api/clients. Décrivez comment vous réaliseriez cet appel HTTP (méthode GET), comment vous traiteriez la réponse et comment vous afficheriez les informations reçues dans une application ou un script.

Vous devez consommer un service SOAP simple qui expose une méthode GetBalance(accountId). Le service utilise un WSDL et retourne la réponse dans un message XML. Décrivez comment vous utilisez le WSDL, comment vous construisez la requête SOAP minimale et comment vous extrayez la valeur du solde dans la réponse XML.

Votre tâche est d’envoyer les informations d’un nouvel utilisateur (nom, email) à un service REST via l’endpoint /api/users. Expliquez comment structurer une requête POST avec un corps JSON, comment définir l’en-tête Content-Type: application/json et comment interpréter la réponse du serveur.

Vous devez consommer un service REST protégé nécessitant un token d’authentification envoyé dans l’en-tête HTTP Authorization: Bearer <token>. L’endpoint /api/orders retourne la liste des commandes associées à un utilisateur connecté. Décrivez comment obtenir le token (via un endpoint /login), comment l’ajouter dans les en-têtes de la requête et comment gérer une erreur d’authentification (401 Unauthorized).

Vous devez appeler un service SOAP qui expose la méthode CreateOrder, nécessitant un objet complexe contenant : les informations du client, une liste d’articles et les modalités de livraison. En utilisant le WSDL, décrivez comment structurer le message SOAP, comment gérer les namespaces XML, quels éléments doivent être obligatoirement présents et comment interpréter la réponse du service.

Un service REST retourne les détails d’une commande via /api/order/42 dans un JSON contenant des objets et tableaux imbriqués (client, adresse, produits, facturation). Vous devez extraire les informations essentielles : nom du client, total de la commande et liste des noms de produits. Décrivez comment parcourir la structure JSON, gérer les champs facultatifs et éviter les erreurs si certains objets sont absents.

Votre mission est de concevoir une API Gateway devant exposer un ensemble de microservices REST et quelques anciens services SOAP. Exigences : routage et transformation (adapter un appel REST vers un backend SOAP et inverse), versioning des APIs, gestion de breaking changes et policies de routage canari, contrôle d’accès (API keys, JWT, scopes) et quotas / rate limiting par client et par endpoint, caching des réponses (TTL, cache key) pour alléger les backends, et invalidation ; instrumentation complète : traces distribuées (headers trace), métriques (latence, taux d’erreur), logs structurés et dashboards (Prometheus/Grafana), + alerting ; stratégies de fallback (circuit breaker, réponse par défaut) et tests de charge pour valider la scalabilité. Décrivez la configuration de la gateway (policies ou pipelines), l’approche pour transformer SOAP↔REST (mapping XML↔JSON, gestion des namespaces), la politique de sécurité et quota, ainsi qu’un plan de tests (fonctionnels, contrats OpenAPI/WSDL, performance, observabilité).

Vous devez concevoir l’endpoint POST /orders d’un service REST responsable de créer une commande composée de plusieurs sous-opérations (validation du stock, réservation d’articles, enregistrement de la commande, notification). Exigences : garantir l’idempotence (gestion des clés d’idempotence pour éviter les doublons lors de retry client), assurer une consistance si la création partielle échoue (stratégies : compensation, saga orchestrée ou outbox pattern), prévoir la reprise et le traitement des requêtes en cas de timeout ou d’erreurs réseau (retries, backoff, circuit breaker), définir les codes HTTP à retourner (201, 202, 409, 500…) et le contrat d’erreur (payload d’erreur structuré), expliquer la gestion des transactions distribuées ou l’alternative (sagas / eventual consistency), et comment tester l’idempotence et la résilience (tests d’intégration simulant retries et pannes). Donnez l’architecture logique, les headers ou en-têtes utilisés (ex : Idempotency-Key), le schéma minimal de la requête/réponse, et les scénarios de test essentiels.

On vous demande de sécuriser un service SOAP exposant des opérations financières sensibles. Le travail doit couvrir : authentification et intégrité via WS-Security (signatures XML, encryption) et gestion des tokens SAML ou certificats X.509 ; mise en place de mutual TLS pour le transport et configuration des keystores/ truststores ; définition d’une policy WSDL (WS-Policy) décrivant exigences de sécurité, et maintien de compatibilité avec des clients hérités ; protection contre les attaques XML (XML External Entity, XML Bomb) et validation stricte du schéma XSD ; gestion des erreurs sécurisée (ne pas divulguer d’informations sensibles) et journalisation conforme (PII masqué, preuve d’audit). Expliquez les fichiers et configurations à modifier (WSDL, policy attachments), comment valider localement avec un client SOAP, et donnez une checklist de tests de sécurité (certificats, replay attacks, XML hardening).