Cela commence par l’appel d’un collègue analyste qui travaille sur un autre projet. Il doit nous transmettre une information récupérée sur le système d’information (SI). La réponse de l’architecte le bloque. L’information doit être récupérée en REST. “Tu comprends !”, m’explique-t-il “Pour moi, SOAP, REST, c’est du chinois.”. S’il avait été patient, je lui aurais expliqué. En 5 minutes, vous allez comprendre.
Les informations gérées par les applications que nous utilisons quotidiennement sont stockées dans des bases de données. Seule l’application ‘A’ peut lire et modifier ces informations. Il peut arriver qu’une autre application ‘B’ veuillent avoir une de ces informations gérée par ‘A’. Pour cela, elle pourrait interroger directement la base. Cela signifierait qu’elle ait un accès direct à la base. Pour des raisons de sécurité, c’est non.
Donc, la solution est que ‘A’ propose un service qui met à disposition la donnée aux autres applications, dont ‘B’. ‘A’ étant accessible depuis internet, ‘B’ peut se trouver à l’autre bout du réseau, il aura accès à la donnée même sans voir la base puisqu’il sait contacter ‘A’. C’est ce qu’on appelle un Web Service (WS) ou service accessible à travers un réseau.
Prenons le cas concret des applications météo. Il existe des centaines d’applications qui vous proposent de consulter la météo de votre ville. Pourtant, les sociétés derrière ces applications ne disposent d’aucune station météo. Ils se contentent d’interroger les services de sociétés spécialisées comme Météo France avant (éventuellement de calculer et) d’afficher les prévisions.
Il existe plusieurs méthodes d’accès à ces services. Les plus connues sont les méthodes SOAP et REST. Je ne sais pas qui a proposé ces noms mais en anglais cela signifie littéralement ‘savon’ et ‘repos’. En fait, il s’agit de 2 méthodes d’accès aux informations dont la philosophie est très différente.
SOAP est la plus ancienne et signifie Simple Object Access Protocol ou “protocole simple d’accès aux objets”. Simple ? Surtout parce qu’il n’est pas lié à une technologie particulière mais qu’il se situe au-dessus du 7éme étage du réseau. Je vous laisse imaginer le cauchemar pour les développeurs avant ce protocole. Parce que SOAP est tout sauf simple à appréhender, même pour un informaticien.
SOAP définit les entrées au service et leurs réponses dans des objets écrits en XML. Difficile à expliquer en quelques mots. Le service peut être caché derrière une adresse internet classique. Tant que le client respecte la structure SOAP convenue (décrite dans la WSDL), le serveur répondra. Afin de simplifier leurs demandes, les développeurs peuvent passer par AJAX (Asynchronous Javascript And XML). Chaque sigle de ce paragraphe pourrait faire l’objet de plusieurs articles. Désolé 🙂
REST est le plus récent et signifie Representational State Transfert ou “transfert d’état représentatif”. L’idée de ce protocole est de prendre les aspects les plus simples des technologies d’Internet :
- un protocole réseau de niveau 7 : HTTP (Hypertext Transfer Protocol),
- un format pour décrire le résultat : JSON (Javascript Object Notation).
Concrètement, pour accéder à un service, il faut interroger une adresse, comme on le fait sur un navigateur. On décrit dans l’adresse d’un service REST les éléments que l’on attend. En retour, la réponse est formaté en Json.
Pour de la prévision météo, le service proposera d’indiquer dans les éléments, le pays, la ville et la date. Par exemple : https://monservicemeteo.fr/ville/lyon/date/19082021. En retour, la réponse sera décrite ainsi : { “météo” : “lyon” : { [“temp_min” : “13°” “temp_max” : 14°” ] } }. Reste au développeur de traiter et d’afficher l’information dans son application.
Par sa simplicité, Jason a donc détrôné Ajax dans le code des développeurs.