Comment fonctionnent les services Web – Les moteurs invisibles du monde connecté

Article original : How Web Services Work – The Unseen Engines of the Connected World

Vous êtes-vous déjà demandé comment votre application météo connaît instantanément les prévisions, comment vous pouvez réserver des vols auprès de plusieurs compagnies aériennes sur un seul site de voyage, ou comment la connexion à un service peut magiquement vous connecter à un autre ?

La réponse réside souvent dans une technologie puissante, mais souvent invisible : les services Web.

Imaginez Internet comme une ville animée. Différents bâtiments (applications) ont des fonctions différentes et sont construits par différents architectes (développeurs) utilisant différents matériaux (langages de programmation et plateformes).

Alors, comment ces bâtiments distincts interagissent-ils efficacement ? Ils ont besoin de routes standardisées, de services de livraison et de protocoles de communication. Les services Web sont l'équivalent numérique de ces composants cruciaux de l'infrastructure urbaine.

Dans cet article, vous apprendrez ce que sont les services Web et pourquoi ils sont importants. Vous découvrirez également les différents types de services Web, comme le protocole Simple Object Access Protocol (SOAP) et le Representational State Transfer (REST), et quand utiliser chacun d'eux. Nous terminerons par quelques exemples pour que vous puissiez les voir en action.

Table des matières :

Qu'est-ce qu'un service Web exactement ?
Pourquoi les services Web sont-ils si importants ?
Types de services Web
Comparaison et contraste des services Web SOAP et REST
Et si un service utilise SOAP et l'autre utilise REST ?
Services Web en action : exemples
Réflexions finales

Qu'est-ce qu'un service Web exactement ?

À la base, un service Web est une méthode standardisée permettant à différentes applications logicielles de communiquer entre elles via un réseau, généralement Internet. Il permet à l'application 'A' (exécutée, par exemple, sur un serveur Windows utilisant Java) de demander des informations ou de déclencher une action depuis l'application 'B' (exécutée sur une machine Linux utilisant Python), sans que l'une ou l'autre application ait besoin de connaître les détails internes complexes de l'autre.

Voici comment ils y parviennent :

Accessibilité réseau : Ils fonctionnent via des protocoles Web standard comme HTTP/HTTPS.
Messagerie standardisée : Ils utilisent des formats de données courants comme XML (Extensible Markup Language) ou JSON (JavaScript Object Notation) pour structurer les données échangées.
Description de l'interface : Ils sont souvent accompagnés d'un "contrat" ou d'une description (comme WSDL pour les services SOAP ou les définitions OpenAPI/Swagger pour les API REST) qui indique aux autres applications comment interagir avec eux – quelles fonctions sont disponibles et quel format de données attendre.

Pourquoi les services Web sont-ils si importants ?

L'essor des services Web a révolutionné le développement logiciel et Internet lui-même. Ils sont importants pour plusieurs raisons clés.

Tout d'abord, l'interopérabilité. C'est le plus grand avantage. Les services Web brisent les silos technologiques. Une application écrite en C# peut communiquer de manière transparente avec une application écrite en Ruby, tant qu'elles s'accordent sur le protocole de service Web et le format de données.

Ensuite, la réutilisabilité. Une entreprise peut construire une fonction spécifique (comme le traitement des paiements ou la vérification des stocks) en tant que service Web une fois. Ensuite, plusieurs applications internes ou externes peuvent réutiliser ce même service, économisant ainsi un temps et des efforts de développement significatifs.

De plus, le couplage lâche. Les applications utilisant un service Web n'ont pas besoin d'être étroitement liées à celui-ci. Le fournisseur de services peut mettre à jour le fonctionnement interne du service sans casser les applications qui l'utilisent, tant que l'interface de communication reste cohérente. Cela rend les systèmes plus flexibles et plus faciles à maintenir.

Et enfin, l'indépendance de la plateforme. Parce qu'ils reposent sur des standards Web, les services Web fonctionnent sur différents systèmes d'exploitation et matériels.

Types de services Web

Les services Web peuvent être largement catégorisés en différents types, chacun avec ses propres caractéristiques et cas d'utilisation appropriés. Les deux types les plus importants sont SOAP et REST. D'autres types incluent XML-RPC, UDDI, GraphQL et gRPC.

SOAP (Simple Object Access Protocol)

Les services Web SOAP sont souvent utilisés dans des applications de niveau entreprise nécessitant une sécurité élevée et une intégrité transactionnelle, comme la banque, la finance et les télécommunications.

Protocole : SOAP (Simple Object Access Protocol) est un protocole formel avec des règles strictes définies par le W3C qui repose sur XML pour le format des messages et généralement HTTP/HTTPS pour la négociation et la transmission des messages.
Structure : Les messages SOAP sont composés d'une enveloppe, d'un en-tête et d'un corps :
- Enveloppe : Définit le début et la fin du message, et inclut les espaces de noms pour les composants.
- En-tête : Contient des attributs optionnels pour le routage des messages et la qualité de service.
- Corps : Contient les informations d'appel et de réponse réelles, enveloppées en XML.
Communication : SOAP est piloté par protocole et utilise WSDL (Web Services Description Language) pour décrire les services offerts et comment interagir avec eux.
Cas d'utilisation : Une requête SOAP peut être utilisée pour appeler un service bancaire afin de vérifier le solde d'un compte. La réponse sera strictement formatée en XML, répondant aux exigences du service.

Exemple : un service Web de conversion de devises

Requête SOAP (XML)

POST /CurrencyService.asmx HTTP/1.1
Host: www.example.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
SOAPAction: "http://www.example.com/ConvertCurrency"

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <ConvertCurrency xmlns="http://www.example.com/">
      <FromCurrency>USD</FromCurrency>
      <ToCurrency>EUR</ToCurrency>
      <Amount>100</Amount>
    </ConvertCurrency>
  </soap:Body>
</soap:Envelope>

Réponse SOAP (XML)

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <ConvertCurrencyResponse xmlns="http://www.example.com/">
      <ConvertCurrencyResult>92.5</ConvertCurrencyResult>
    </ConvertCurrencyResponse>
  </soap:Body>
</soap:Envelope>

Architecture SOAP

REST (Representational State Transfer)

Les services Web REST sont souvent utilisés pour construire des API qui permettent aux applications d'effectuer des opérations CRUD sur des ressources, comme la récupération de données depuis une base de données ou l'interaction avec d'autres services. REST est particulièrement populaire dans le développement Web car il est relativement simple, très scalable et utilise des méthodes HTTP standard (GET, POST, PUT, DELETE).

Architecture : REST (Representational State Transfer) est un style architectural plutôt qu'un protocole. Il repose sur des méthodes HTTP standard comme GET, POST, PUT, DELETE, pour interagir avec des ressources.
Échange de données : REST échange généralement des données au format JSON ou XML. JSON est plus courant en raison de sa nature légère.
Structure : REST n'a pas de contrat formel comme WSDL. Au lieu de cela, les ressources sont identifiées via des URL, et les codes de statut HTTP indiquent le résultat des requêtes.
Généralement considéré comme plus simple, plus flexible et scalable, ce qui le rend extrêmement populaire pour les applications Web et mobiles (ceux-ci sont souvent appelés API RESTful).
Cas d'utilisation : Une API REST peut être utilisée pour récupérer des données sur un livre dans une application de librairie, en utilisant une simple requête HTTP GET.

Exemple : un service Web de conversion de devises

Requête REST

GET /api/convert?from=USD&to=EUR&amount=100 HTTP/1.1
Host: www.example.com

En utilisant POST :

POST /api/convert HTTP/1.1
Host: www.example.com
Content-Type: application/json

{
  "from": "USD",
  "to": "EUR",
  "amount": 100
}

Réponse REST (JSON)

{
  "from": "USD",
  "to": "EUR",
  "amount": 100,
  "result": 92.5
}

Architecture REST

Dans le développement Web moderne, en particulier pour les API publiques et les microservices, REST (surtout en utilisant JSON sur HTTPS) est devenu l'approche la plus populaire et souvent préférée en raison de sa simplicité et de ses avantages en termes de performance. Mais SOAP reste pertinent et nécessaire dans des contextes d'entreprise spécifiques.

Comparaison et contraste des services Web SOAP et REST

Fonctionnalité	SOAP	REST
Type	Protocole	Style architectural
Standards	Strictement définis, repose sur des standards comme WS-Security	Faiblement définis, suit les standards HTTP
Format de données	Principalement XML	Supporte divers formats (JSON, XML, HTML, texte brut), JSON est courant
Bande passante/Ressources	Plus nécessaire en raison du XML verbeux	Moins nécessaire, léger
Sécurité	Fonctionnalités de sécurité intégrées (WS-Security), support du chiffrement	Hérite de la sécurité du transport sous-jacent (HTTPS), des mécanismes supplémentaires comme OAuth peuvent être utilisés
Logique métier	Exposée via des interfaces de service	Exposée via des URI représentant des ressources
Facilité d'utilisation	Peut être complexe, nécessite des outils spécifiques, courbe d'apprentissage plus raide	Généralement plus facile à construire et à consommer, courbe d'apprentissage plus courte
Performance	Peut être plus lent en raison de la surcharge d'analyse XML	Meilleure performance, surtout avec JSON et mise en cache
Scalabilité	Peut être difficile à mettre à l'échelle en raison de la gestion d'état (si utilisée)	Plus facile à mettre à l'échelle en raison de la nature sans état
Transport	Indépendant du transport (HTTP, SMTP, TCP, JMS)	Utilise principalement HTTP
Gestion des erreurs	Gestion des erreurs intégrée avec des codes de faute standardisés	Repose sur les codes de statut HTTP et parfois des réponses d'erreur personnalisées
Mise en cache	Les appels SOAP ne sont généralement pas mis en cache (surtout avec POST)	Les réponses REST peuvent être mises en cache
État	Supporte les opérations avec et sans état	Principalement sans état
Outillage	Nécessite des toolkits SOAP spécifiques pour le développement et la consommation	Peut être implémenté avec des bibliothèques et outils HTTP standard
Documentation	Utilise WSDL pour la description des services	La documentation repose souvent sur la spécification OpenAPI (Swagger) ou des outils similaires
Cas d'utilisation	Applications d'entreprise, transactions complexes, exigences de sécurité élevées, opérations asynchrones, opérations avec état (si nécessaire)	Applications Web, applications mobiles, API publiques, services simples et scalables, scénarios avec bande passante limitée

Et si un service utilise SOAP et l'autre utilise REST ?

Par défaut, SOAP et REST ne sont pas directement compatibles car SOAP utilise XML avec un format de message strict, et REST utilise des méthodes HTTP et souvent des charges utiles JSON.

Ils ne peuvent donc pas communiquer directement entre eux sans une couche d'intégration ou un adaptateur. Voici comment vous pouvez gérer cette situation :

Utiliser des services intermédiaires : Vous pouvez utiliser un middleware ou une passerelle API qui peut gérer à la fois les protocoles SOAP et REST. Ces services peuvent traduire les requêtes SOAP en requêtes REST et vice-versa.
Utiliser des adaptateurs : Écrire des adaptateurs qui convertissent les messages XML SOAP en requêtes JSON REST. Essentiellement, un logiciel agit comme un traducteur entre les deux formats.
Intégration directe : Bien que complexe, cela implique un développement logiciel personnalisé où le service SOAP peut être configuré manuellement pour invoquer des points de terminaison REST.
Utiliser un ESB (Enterprise Service Bus) : Un ESB peut intégrer des applications et des formats de données divers au sein de l'architecture d'entreprise, agissant comme un médiateur qui comprend à la fois SOAP et REST.
Exposer une API hybride : Certaines API modernes exposent à la fois des points de terminaison SOAP et REST pour la même logique backend.
- Exemple : Amazon Web Services (AWS) avait des API SOAP et REST pour certains services. Cela permet aux clients de choisir le protocole qu'ils préfèrent.

Services Web en action : exemples

Applications météo : Votre application mobile appelle probablement un service Web météo, envoyant votre localisation et recevant en retour des données de prévision.
Paiements en ligne : Lorsque vous achetez quelque chose en ligne, le site de commerce électronique communique souvent avec un service Web de passerelle de paiement pour traiter de manière sécurisée les informations de votre carte de crédit.
Agrégateurs de voyage : Des sites comme MakeMyTrip ou Kayak utilisent les services Web fournis par les compagnies aériennes et les hôtels pour obtenir en temps réel la disponibilité et les prix des vols et des chambres.
Connexions sociales : Les boutons "Se connecter avec Google" ou "Se connecter avec Facebook" utilisent des services Web d'authentification (souvent basés sur OAuth) pour vérifier votre identité sans que vous ayez besoin d'un mot de passe séparé pour ce site.

Réflexions finales

Les services Web ont fondamentalement transformé la manière dont les applications interagissent et échangent des données sur les réseaux. Leur capacité à faciliter l'interopérabilité, la réutilisabilité et la scalabilité les a rendus indispensables dans le développement logiciel moderne et l'intégration des systèmes.

Bien que SOAP et REST représentent les deux styles dominants, chacun avec ses forces et ses faiblesses, leur choix dépend souvent des exigences spécifiques du projet, en particulier en matière de sécurité, de performance et de complexité.

Comprendre les fonctionnalités de base, les technologies sous-jacentes, les cas d'utilisation courants et les considérations de sécurité des services Web fournit une base solide pour naviguer dans le paysage de l'informatique distribuée.