Historiquement, un Web Service est un ensemble de méthode permettant d’executer et de retourner le résultat d’une fonction en s’appuyant sur les protocoles du Web.
Vous ne voyez pas le concept ? c’est normal, ça mobilise beaucoup de concepts
Prenons un exemple en imaginant que vous voulez calculer le résultat de l’opération 1+1 en utilisant un web service créé pour faire des calculs.
Vous aller alors faire les opérations suivantes :
- Préparer un fichier XML qui contient les termes (ou opérandes) de votre calcul
- Appeler l’url du web service “addition” et lui envoyer le fichier préparé
- Récupérer le résultat de l’appel, également sous forme XML
- Extraire le résultat dans la réponse XML
Ca a l’air compliqué pour par grand chose, non ?
Et oui, du calcul mental ou une calculatrice aurait été plus simple.
Mais l’intérêt des Web Service est ailleurs : les Web Services normalisent :
- La façon de transmettre des paramètres
- La façon d’appeler le Web Service
- La façon de transmettre les résultats
Autrement dit : si une société met à disposition un Web Service qui respecte les standards, une autre société pourra faire appel à ce Web Service.
Ceci permet la création d’architectures orientées services (SOA = Service Oriented Architecture) où on interroge plusieurs fournisseurs de Web Services.
Les Web Services s’appuient sur les 3 protocoles suivants :
- SOAP (Simple Object Access Protocol) : pour la transmission des arguments en XML
- WSDL (Web Service Description Language) : pour la description des services Web, les arguments et types d’arguments acceptés, les résultats et types de résultats acceptés
- UDDI (Universal Description Discovery and Integration) : pour fabriquer des annuaires de Web Services
Ces 3 protocoles sont rigides et assez verbeux (beaucoup d’informations transmises) et on voit depuis plusieurs années progresser une alternative : les API REST
Les principes fondamentaux sont les mêmes :
- Utilisation d’un standard pour encoder les paramètres ou les résultats (on utilise JSON de préférence à XML, car JSON est plus léger et beaucoup moins verbeux)
- Norme de facto pour l’appel des fonctions
Il manque cependant :
- la possibilité de récupérer de façon automatique les descriptions des fonctions ou les arguments, réponses et types (mais des outils comme “swagger” essayent de compenser ce manque)
- un annuaire centralisé d’API REST
La similarité fonctionnelle entre les Web Service historiques et les API REST font que l’on entend de plus en plus souvent parler de Web Service lorsqu’en fait on parle d’API REST. Ceci est un abus de langage mais peut se comprendre…