JSON, REST, SOAP, WSDL et SOA: comment relient-ils tous ces liens?
Je suis actuellement en train de passer des examens et j'ai du mal à trouver certains concepts. Celles-ci ont toutes été "mentionnées" dans mes notes mais je ne comprenais pas vraiment comment elles étaient liées. Pour autant que je sache,
SOA - une solution permettant aux consommateurs/fournisseurs de services de communiquer. (autant que je sache, c'est le terme générique pour tout le reste)
WSDL - Langage décrivant le service du fournisseur.
SOAP - Un 'wrapper' de protocole XML utilisé par les services pour envoyer des messages. Fonctionne en conjonction avec WSDL pour fournir des paramètres?
REST - Un modèle de conception similaire à SOAP in, mais qui évite le XML? (vraiment pas sûr de celui-ci)
JSON - Une alternative au XML qui utilise javascript? (pas sûr de celui-ci non plus)
En regardant sur Internet, il ne semble pas y avoir de définition claire de ce que sont tous ces éléments et de la manière dont ils sont liés.
Imaginez que vous développiez une application Web et que vous décidiez de découpler les fonctionnalités de la présentation de l'application, car elles offrent une plus grande liberté.
Vous créez une API et laissez les autres implémenter leurs propres interfaces également. Ce que vous venez de faire ici est d’implémenter une méthodologie SOA , c’est-à-dire utiliser des services Web.
Les services Web rendent les blocs fonctionnels fonctionnels accessibles via des protocoles Internet standard, indépendamment des plateformes et des langages de programmation.
Vous concevez donc un mécanisme d’échange entre le back-end (service Web) qui traite et génère quelque chose d’utile, et le front-end (qui consomme les données), qui peut être n'importe quoi. (Une application Web, mobile ou de bureau, ou un autre service Web). La seule limitation ici est que le front-end et le back-end doivent "parler" le même "langage".
C'est là que SOAP et REST entrent en jeu. Ce sont des moyens standard de communication avec le service Web.
SOAP:
SOAP utilise en interne XML pour envoyer des données en arrière. Les messages SOAP ont une structure rigide et le XML de réponse doit ensuite être analysé. WSDL spécifie quelles demandes peuvent être effectuées, avec quels paramètres et ce qu'elles renverront. C'est une spécification complète de votre API.
REST:
REST est un concept de design.
Le World Wide Web représente la plus grande implémentation d’un système conforme au style architectural REST.
Ce n'est pas aussi rigide que SOAP. services Web RESTful utilisent des URI et des méthodes standard pour passer des appels vers le service Web. Lorsque vous demandez un URI, il renvoie la représentation d'un objet sur lequel vous pouvez ensuite effectuer des opérations (par exemple, GET, PUT, POST, DELETE). Vous n'êtes pas limité à choisir XML pour représenter des données, vous pouvez choisir n'importe quoi (JSON inclus)
L'API REST de Flickr va plus loin et vous permet également de renvoyer des images.
JSON et XML, sont fonctionnellement équivalents et communs les choix. Il existe également des frameworks basés sur RPC, tels que GRPC basé sur Protobufs et Apache Thrift, qui peuvent être utilisés pour la communication entre les producteurs d'API et les consommateurs. Le format le plus couramment utilisé par les API Web est JSON, car il est facile à utiliser et à analyser dans toutes les langues.
WSDL: représente le langage de description de service Web
Dans SOAP (protocole simple d'accès aux objets), lorsque vous utilisez un service Web et ajoutez un service Web à votre projet, vos applications clientes ne connaissent pas les fonctions de service Web. De nos jours, c'est un peu démodé et pour chaque type de client, vous devez implémenter différents fichiers WSDL. Par exemple, vous ne pouvez pas utiliser le même fichier pour le client .Net et php. Le fichier WSDL contient des descriptions sur les fonctions de service Web. Le type de ce fichier est XML. SOAP est une alternative à REST.
RESTE: signifie un transfert d'état représentationnel
C'est un autre type de service API, il est vraiment facile à utiliser pour les clients. Il n’est pas nécessaire qu’ils aient une extension de fichier spéciale comme les fichiers WSDL. L’opération CRUD peut être implémentée par différents HTTP Verbs (GET pour la lecture, POST pour la création, PUT ou PATCH pour la mise à jour et DELETE pour la suppression du document souhaité). Ils sont basés sur le protocole HTML. fois où la réponse est au format JSON ou XML. D'autre part, l'application cliente doit appeler exactement le HTTP Verb associé via les noms et types de paramètres exacts. En raison de l'absence de fichier spécial pour la définition, tel que WSDL, il s'agit d'un travail manuel utilisant le noeud final. Mais ce n'est pas un gros problème car nous avons maintenant beaucoup de plugins pour différents IDE pour générer l'implémentation côté client.
SOA: représente l'architecture orientée service
Inclut toute la programmation avec les concepts et l’architecture des services Web. Imaginez que vous souhaitiez implémenter une application à grande échelle. Une pratique peut consister à disposer de différents services, appelés micro-services, et l'ensemble du mécanisme de l'application consiste à appeler le service Web nécessaire au bon moment. Les services Web REST et SOAP sont des types de SOA.
JSON: signifie javascript Object Notation
lorsque vous sérialisez un objet pour javascript, le type de format d'objet est JSON. imaginez que vous avez la classe humaine:
class Human{
string Name;
string Family;
int Age;
}
et vous avez quelques exemples de cette classe:
Human h1 = new Human(){
Name='Saman',
Family='Gholami',
Age=26
}
lorsque vous sérialisez l'objet h1 en JSON, le résultat est le suivant:
[h1:{Name:'saman',Family:'Gholami',Age:'26'}, ...]
javascript peut évaluer ce format par la fonction eval() et créer un tableau associatif à partir de cette chaîne JSON. Celui-ci est un concept différent par rapport aux autres concepts que j'ai décrits précédemment.