web services tutorial
Ce didacticiel sur les services Web explique l'architecture, les types et les composants d'un service Web ainsi que les terminologies importantes et les différences entre SOAP et REST:
Dans ce Série complète de didacticiels de test d'API , nous avons tout exploré Test API dans notre tutoriel précédent. Suivez ce didacticiel pour vous familiariser avec WSDL et UDDI et comment ils stockent et définissent un service Web.
Ce didacticiel explique également comment les services Web fonctionnent en interne lorsqu'une application cliente fait une demande. WSS, qui est un autre concept très important des services SOAP, est également expliqué ici.
Ce que vous apprendrez:
Terminologies importantes dans les tests de service Web
Avant de commencer à explorer les services Web, nous devons nous familiariser avec les termes importants utilisés dans les tests de services Web.
Commençons!!
# 1) Interopérabilité
Les services Web prennent en charge «One Code Different Applications». Cela signifie un code générique pour toutes les applications sur différentes plates-formes.
Ainsi, l'interopérabilité est le processus qui permet à plusieurs applications de communiquer avec les autres applications résidant sur une plate-forme différente.
# 2) Authentification et autorisation
Ceux-ci sont principalement utilisés dans les services Web SOAP. En termes généraux, l'authentification signifie valider quelque chose tandis que l'autorisation signifie donner / avoir le droit d'accéder à quelque chose.
Par exemple - Si j'ai une page Facebook, je peux être traité comme un utilisateur authentifié de Facebook. Alors que si vous avez le droit de voir mes photos sur Facebook, vous êtes un utilisateur autorisé.
En combinant ces deux éléments, nous pouvons dire que «Tous les utilisateurs authentifiés qui ont accès aux ressources sont appelés utilisateurs autorisés pour ces ressources.»
La même chose se produit dans les services Web, c'est-à-dire que l'ID utilisateur et le mot de passe utilisés pour générer le jeton couvrent la partie d'authentification et ce jeton qui sera utilisé pour envoyer une demande au serveur Web couvre la partie d'autorisation.
# 3) Architecture faiblement couplée
Les services Web sont basés sur une architecture à couplage lâche. Cela signifie que les interfaces des services Web sont de nature dynamique (changements au cours d'une chronologie donnée). Mais la logique client ne doit pas nécessairement changer lors de l'interaction avec le service.
Cela facilite l'intégration de plusieurs logiciels d'une manière plus efficace. S'il s'agissait d'une architecture étroitement couplée, à chaque fois que l'interface change, la logique du client doit être modifiée pour la synchroniser avec le service.
# 4) Artefact
C'est un terme utilisé dans les services Web pour désigner des informations ou des données. Ce ne sont pas les données complètes mais un élément d'information qui peut inclure une URL ou un URI, une clé de contexte, une clé de document, une charge utile ou des images de support.
# 5) Point final
C'est un terme très courant qui est utilisé dans chaque demande du service Web. Il s'agit de l'URL complète qui accède à l'instance du service Web.
Par exemple - https://www.facebook.com/imsaket -> c'est l'URL complète ou le point final qui a facebook.com comme URL et «imsaket» est passé comme clé de contexte pour identifier de manière unique une adresse spécifique.
informatica interview questions et réponses pdf
# 6) Idempotent
Il s'agit de l'interaction client-serveur dans laquelle le nombre de fois où vous frappez l'instance du service n'a pas d'importance et le serveur renverra toujours la même réponse au client.
# 7) Marshalling Et Demarshalling
Comme nous le savons, l'encapsulation est un principe OOPS qui est défini comme le regroupement du code et des données en un seul. La même chose se produit dans les services Web SOAP. Lorsque nous enveloppons ou encapsulons des données dans une charge utile (XML) pour former un message SOAP et l'envoyer au serveur, ce processus d'encapsulation est appelé Marshalling.
Le demarshalling n'est que la réciproque du Marshalling. La méthode de décapsulation ou de désemballage des données et du code (XML) du message SOAP est appelée «démarshalling».
Qu'est-ce qu'un service Web?
Comme indiqué précédemment, les services Web sont les services qui servent d'une machine à une autre sur un réseau.
Exemple de services Web: AWS (Amazon Web Services) qui permet aux utilisateurs en ligne de consulter les prix des différents articles vendus sur Amazon.com et Amazon.in
Composants des services Web
Vous trouverez ci-dessous les différents composants des services Web.
# 1) SAVON
Les services Web utilisent le protocole SOAP (Simple Object Access Protocol) qui utilise XML comme charge utile ou corps de requête. C'est un protocole avec état car il n'y a pas de méthode indépendante pour le type d'opération spécifique.
Toutes les demandes et réponses sont transmises en même temps via XML et aucune méthode indépendante comme GET, PUT, POST ou DELETE n'est explicitement fournie.
# 2) WSDL
Cette requête SOAP utilise Langage de description de services Web (WSDL) qui est un composant très utile du service Web.
Cela définit où réside réellement le service Web et également le type de service Web à récupérer pour une demande spécifique. Cela utilise un fichier XML qui décrit la fonctionnalité du service Web.
# 3) UDDI
Un autre élément utile est UDDI . Cela signifie Universal Description Discovery and Integration. Il existe un fournisseur de services qui fournit le service Web. Par conséquent, pour un fournisseur de services particulier, cet UDDI est utilisé pour décrire, découvrir et publier ces services Web.
UDDI est chargé de laisser un client découvrir (UDDI fournit un référentiel pour WSDL) où se trouve le fichier XML du WSDL. C'est ainsi qu'un service Web est défini et décrit.
# 4) XML-RPC
Il signifie Extensible Markup Language - Remote Procedure. Un autre composant très important du service Web est XML - RPC qui est responsable de l'envoi de messages à travers les systèmes. Les demandes et les réponses sont sous forme de XML et sont envoyées / reçues via HTTP POST.
La meilleure caractéristique de XML-RPC est qu'une application client résidant sur une plate-forme différente peut communiquer avec un serveur différent. Il y a quelque chose appelé JSON-RPC qui a été expliqué dans la dernière partie de l'article car il ne forme pas un composant d'un service Web.
L'architecture d'un service Web
L'architecture d'un service Web peut être représentée dans le diagramme suivant.
Comme nous le savons déjà, une architecture de services Web typique comprend trois entités à savoir un client, un serveur Web et un Internet pour effectuer l'opération. L'opération n'est rien d'autre que la requête et la réponse dans une architecture client-serveur.
Un client est généralement un ensemble de toutes les applications ou systèmes logiciels qui demandent un service Web, ce qui en fait un consommateur de service.
Un serveur Web est un ensemble de toutes les applications ou systèmes logiciels qui fournissent un service Web. Chaque service Web nécessite un réseau pour fonctionner et cela se traduit par la troisième entité appelée Internet.
Ceci n'est qu'un aperçu de l'architecture d'un service Web.
Le diagramme de fonctionnement d'un service Web est défini par les trois composants indiqués ci-dessous.
- Demandeur de service (Rechercher ())
- Fournisseur de services (Publier ())
- Registre de service ou référentiel (Bind ())
Ceci est expliqué (en détail avec schéma) dans l'architecture du service SOAP.
comment ouvrir un fichier json
Types de services Web
Deux types de services Web sont expliqués ci-dessous en détail.
# 1) Service SOAP
SOAP Service signifie Simple Object Access Protocol. Les services SOAP sont des services avec état qui utilisent le langage XML pour former une enveloppe. Une enveloppe SOAP peut être décrite en deux parties, c'est-à-dire que l'une est un En-tête et corps SOAP , l'autre est le protocole utilisé pour envoyer des messages SOAP.
Cet en-tête SOAP se compose de l'authentification et de l'autorisation qui accorde l'accès. Le corps fait partie de la section payload de la requête qui utilise WSDL pour décrire le service Web et le protocole est principalement HTTP (HyperText Transmission Protocol).
Sécurité des services Web
Les services SOAP disposent d'une couche SSL (Secure Socket Layer) qui est chargée d'éviter toute fuite de données lors de la transmission, et assure ainsi le cryptage et le décryptage.
Pendant ce temps, les services SOAP sont plus sécurisés car il dispose également de WSS (Web Services Security) qui garantit aucune divulgation lors de la communication entre le service et l'application.
Comme nous le savons tous, chaque service Web (contrairement à l'API Web), a besoin d'un réseau pour effectuer son fonctionnement. Ainsi, il devient nécessaire pour les services Web d'assurer la sécurité lorsqu'ils sont connectés à un réseau. Par conséquent, les services Web ont trois entités importantes pour couvrir le facteur de sécurité pendant le transfert des messages.
- Authentification et autorisation (Déjà expliqué ci-dessus).
- Confidentialité: Cela dépend entièrement du SSL qui assure le cryptage et le décryptage de l'enveloppe SOAP.
- Sécurité Internet: Cela signifie extraire toutes les réponses SOAP et XML-RPC que vous obtenez du serveur. Par exemple, Si vous utilisez un outil de service Web comme POSTMAN ou PARASOFT, vous trouverez que sous le gestionnaire d'en-tête HTTP, il existe une option pour définir la valeur du Content-Type. La valeur peut être définie sur Application / JSON afin d'extraire tous les REST (puisque les services SOAP ne prennent pas en charge les options du gestionnaire d'en-tête HTTP). Ainsi, vous pouvez passer le type de contenu: Application / XML dans un charge utile lui-même sous la forme de XML. Cela extrairait également SOAP et XML-RPC.
Ces trois facteurs constituent la sécurité des services Web pour faire face aux attaques externes.
L'architecture du service SOAP
Chaque service SOAP dépend de trois entités qui forment finalement l'architecture du service SOAP.
- Fournisseur de services: Tous les systèmes logiciels ou applications qui font partie ou fournissent un service Web.
- Demandeur de service: Tous les systèmes logiciels ou applications qui font partie des demandes de service Web du fournisseur de services.
- Registre des services: Registre ou référentiel dans lequel toutes les informations sur le service Web sont fournies par le fournisseur de services. (Déjà discuté dans UDDI)
Explication
Ces trois entités interagissent les unes avec les autres pour mener à bien une implémentation de service Web. Cela se fait en trois phases. La première phase est la Publier() phase où un fournisseur de services alimente tous les détails sur un service Web dans un registre de services ou un référentiel.
La deuxième phase est Trouver() où une demande de service principalement l'application cliente trouve les détails sur le service Web à partir d'un référentiel (a également un fichier XML WSDL). La dernière phase est Obligatoire() où l'application cliente ou le demandeur de service se synchronise avec le fournisseur de services pour l'implémentation finale du service Web.
# 2) Service RESTful
REST signifie Representational State Transfer qui est un Apatride Un service.
Il est appelé Stateless car le serveur Web ne stocke aucune information sur la session client (durée jusqu'à ce que l'application cliente soit connectée et en exécution), ce qui signifie que chaque type de requête est traité et exécuté facilement à l'aide de méthodes intégrées REST comme GET, POST, CUSTOM (PUT), DELETE, HEAD et ainsi de suite.
En effet, ces méthodes ne sont pas présentes dans SOAP.
différence entre la stratégie de test et le plan de test
Méthode ou verbes
Chaque méthode de REST a sa signification. Ci-dessous se trouve le briefing sur chacun d'eux.
- OBTENIR: Cette méthode est utilisée pour récupérer les informations envoyées au serveur à l'aide de l'une des méthodes telles que PUT ou POST. Cela n'a pas de corps de requête. Une exécution réussie vous donnera 200 objets de réponse.
- PUBLIER: Cette méthode est utilisée pour créer un document ou un enregistrement à l'aide d'un corps de requête, d'une URL spécifiée, d'une clé de document, d'une clé de contexte, etc. La même chose peut être récupérée à l'aide de la méthode GET. Une exécution réussie vous donnera une réponse 201.
- METTRE: C'est sous l'option CUSTOM qui est disponible dans POSTMAN ou PARASOFT. Cette méthode est utilisée pour mettre à jour tout document ou enregistrement déjà présent. Une exécution réussie vous donnera une réponse 201 ou 200.
- EFFACER: Cette méthode est utilisée pour supprimer n'importe quel enregistrement. Une exécution réussie vous donnera une réponse 204 (aucun contenu).
Remarque: Les codes de réponse HTTP dépendent de la manière dont les développeurs codent et peuvent parfois être manipulés. Nous avons répertorié les codes de réponse courants que nous obtenons de chaque type de méthode.
L'architecture du service REST
L'architecture du service REST dépend de deux entités, à savoir le consommateur de service ou le demandeur et le fournisseur de services. Le consommateur de services est celui qui utilise le service Web et le fournisseur de services est l'ensemble de logiciels ou de système qui fournit le service Web.
L'application cliente qui est généralement un consommateur de service utilise des méthodes intégrées de REST, une URL ou un URI, une version HTTP et une charge utile (si pris en charge par la méthode).
SOAP vs REST
Bien que ces deux types de services Web soient utilisés pour exécuter la demande et la réponse, ils sont entièrement différents dans leur mode de fonctionnement.
Leurs différences sont répertoriées à titre indicatif.
- L'enveloppe SOAP peut être utilisée dans le REST mais pas l'inverse. Par exemple. Un jeton utilisateur créé dans SOAP peut être transmis dans la requête REST sous le gestionnaire d'en-tête HTTP -> Autorisation.
- SOAP est généralement plus sécurisé que les services REST car les services SOAP fournissent WSS en dehors de SSL. Ce SSL est présent à la fois dans SOAP et REST.
- SOAP est plus lent que REST car le traitement de la demande prend plus de temps dans SOAP en raison du format de données XML. REST utilise JSON qui est très léger et le rend donc plus rapide.
- SOAP n'a pas de méthode intégrée mais REST a GET, PUT, POST, etc.
- SOAP est avec état tandis que REST est sans état.
- Les corps de requête et de réponse dans SOAP ne prennent en charge que le format de données XML. Dans REST, les corps de requête et de réponse prennent en charge de nombreux formats de données tels que JSON, XML, texte brut, etc.
Conclusion
Ce didacticiel sur les services Web a expliqué l'architecture, les composants et les types de services Web.
Nous avons également découvert les différences entre les services SOAP et REST, ainsi que d'autres concepts et terminologies importants liés aux services Web.
Nous espérons que ce tutoriel vous a aidé à comprendre les services Web !!
Tutoriel PREV | Tutoriel SUIVANT
lecture recommandée
- Tutoriel Python DateTime avec des exemples
- Tutoriel Java SWING: Conteneur, composants et gestion des événements
- Tutoriel d'injection HTML: types et prévention avec des exemples
- Tutoriel de script Unix Shell avec des exemples
- Tutoriel de recherche d'élément par texte de sélénium avec des exemples
- Tutoriel sur les fonctions principales de Python avec des exemples pratiques
- Tutoriel de test par paires ou de test toutes paires avec outils et exemples
- Tutoriel de test de configuration avec des exemples