web services tutorial
Este tutorial de servicios web explica la arquitectura, los tipos y los componentes de un servicio web junto con terminologías importantes y las diferencias entre SOAP Vs REST:
En esto Serie completa de tutoriales de pruebas de API , exploramos todo sobre Prueba de API en nuestro tutorial anterior. Siga este tutorial para familiarizarse con WSDL y UDDI y cómo almacenan y definen un servicio web.
Este tutorial también explicará cómo funcionan los servicios web internamente cuando una aplicación cliente realiza una solicitud. WSS, que es otro concepto muy importante de los servicios SOAP, también se explica aquí.
Lo que vas a aprender:
- Terminologías importantes en las pruebas de servicios web
- ¿Qué es un servicio web?
- Conclusión
Terminologías importantes en las pruebas de servicios web
Antes de comenzar a explorar los servicios web, debemos estar familiarizados con los términos importantes que se utilizan en las pruebas de servicios web.
¡¡Empecemos!!
# 1) Interoperabilidad
Los servicios web admiten 'Aplicaciones diferentes de un código'. Esto significa un código genérico para todas las aplicaciones en diferentes plataformas.
Por lo tanto, la interoperabilidad es el proceso que facilita que múltiples aplicaciones se comuniquen con otras aplicaciones que residen en una plataforma diferente.
# 2) Autenticación y autorización
Se utilizan principalmente en servicios web SOAP. En términos generales, la autenticación significa validar algo, mientras que la autorización significa dar / tener el derecho de acceder a algo.
Por ejemplo - Si tengo una página de Facebook, entonces puedo ser tratado como un usuario autenticado de Facebook. Considerando que, si tiene derecho a ver mis fotos en Facebook, entonces es un usuario autorizado.
Combinando estos dos podemos decir que 'Todos los usuarios autenticados que tienen acceso a los recursos se conocen como Usuarios autorizados para esos recursos'.
Lo mismo sucede en los servicios web, es decir, la identificación de usuario y la contraseña que se utiliza para generar el token cubre la parte de autenticación y este token que se utilizará para enviar una solicitud al servidor web cubre la parte de autorización.
# 3) Arquitectura débilmente acoplada
Los servicios web se basan en una arquitectura de acoplamiento flexible. Esto significa que las interfaces de los servicios web son de naturaleza dinámica (cambios durante una línea de tiempo determinada). Pero la lógica del cliente no tiene por qué cambiar necesariamente al interactuar con el servicio.
Esto facilita la integración de múltiples software de una manera más eficiente. Si se trataba de una arquitectura estrechamente acoplada, cada vez que cambia la interfaz, la lógica del cliente debe cambiarse para sincronizarla con el servicio.
# 4) Artefacto
Es un término que se utiliza en los servicios web para denotar información o datos. No se trata de todos los datos, sino de una información que puede incluir una URL o URI, una clave de contexto, una clave de documento, una carga útil o imágenes de apoyo.
# 5) Punto final
Este es un término muy común que se utiliza en todas las solicitudes del servicio web. Esta es la URL completa que llega a la instancia del servicio web.
Por ejemplo - https://www.facebook.com/imsaket -> esta es la URL completa o el punto final que tiene facebook.com como la URL y 'imsaket' se pasa como una clave de contexto para identificar de forma única una dirección específica.
cómo reproducir un archivo mkv en Windows
# 6) idempotente
Esto es en la interacción cliente-servidor en la que no importa cuántas veces acceda a la instancia del servicio, y el servidor siempre devolverá la misma respuesta al cliente.
# 7) Marshalling y Demarshalling
Como sabemos, la encapsulación es un principio de OOPS que se define como la agrupación de código y datos en uno. Lo mismo ocurre con los servicios web SOAP. Cuando envolvemos o encapsulamos datos en una carga útil (XML) para formar un mensaje SOAP y enviarlo al servidor, este proceso de encapsulación se llama Marshalling.
Demarshalling es simplemente el recíproco de Marshalling. El método de desencapsular o desenvolver datos y código (XML) del mensaje SOAP se llama 'Demarshalling'.
¿Qué es un servicio web?
Como se mencionó anteriormente, los servicios web son los servicios que sirven de una máquina a otra a través de una red.
Ejemplo de servicios web: AWS (Amazon Web Services) que permite a los usuarios en línea ver los precios de diferentes artículos vendidos en Amazon.com y Amazon.in
Componentes de los servicios web
A continuación se enumeran los diversos componentes de los servicios web.
# 1) JABÓN
Los servicios web utilizan el Protocolo simple de acceso a objetos (SOAP), que utiliza XML como carga útil o cuerpo de solicitud. Esto es un protocolo con estado ya que no existe un método independiente para el tipo específico de operación.
Todas las solicitudes y respuestas se realizan a la vez a través de XML y no se proporcionan explícitamente métodos independientes como GET, PUT, POST o DELETE.
# 2) WSDL
Esta solicitud SOAP hace uso de Lenguaje de descripción de servicios web (WSDL) que es un componente muy útil de Web Service.
Esto define dónde reside realmente el servicio web y también el tipo de servicio web que se recogerá para una solicitud específica. Esto hace uso de un archivo XML que describe la funcionalidad del servicio web.
# 3) UDDI
Otro componente útil es UDDI . Esto significa Descubrimiento e Integración de Descripción Universal. Existe un proveedor de servicios que proporciona el servicio web. Por lo tanto, para un proveedor de servicios en particular, este UDDI se utiliza para describir, descubrir y publicar esos Servicios Web.
UDDI es responsable de permitir que un cliente averigüe (UDDI proporciona un repositorio para WSDL) dónde se encuentra el archivo XML de WSDL. Así es como se define y describe un servicio web.
# 4) XML-RPC
Significa Lenguaje de marcado extensible - Procedimiento remoto. Otro componente muy importante del servicio web es XML - RPC, que se encarga de enviar mensajes a través de los sistemas. Las solicitudes y respuestas están en forma de XML y se envían / reciben a través de HTTP POST.
La mejor característica de XML-RPC es que una aplicación cliente que reside en una plataforma diferente puede comunicarse con un servidor diferente. Hay algo llamado JSON-RPC que se ha explicado en la última parte del artículo, ya que no forma parte de un servicio web.
La arquitectura de un servicio web
La arquitectura de un servicio web se puede representar en el siguiente diagrama.
Como ya sabemos, una arquitectura típica de Servicios Web comprende tres entidades, es decir, un Cliente, un Servidor Web e Internet para llevar a cabo la operación. La operación no es más que la solicitud y la respuesta en una arquitectura cliente-servidor.
Un Cliente es típicamente un conjunto de todas las aplicaciones o sistemas de software que solicita un Servicio Web, convirtiéndolo así en un Consumidor de Servicios.
Un servidor web es un conjunto de todas las aplicaciones o sistemas de software que proporcionan un servicio web. Cada servicio web requiere una red para funcionar y esto da como resultado la tercera entidad llamada Internet.
Esta es solo una descripción general de la arquitectura de un servicio web.
El diagrama de funcionamiento de un servicio web se define mediante los tres componentes que se muestran a continuación.
- Solicitante de servicio (Buscar ())
- Proveedor de servicios (Publish ())
- Registro de servicio o repositorio (Bind ())
Esto se explica (en detalle con el diagrama) en la arquitectura del servicio SOAP.
mejor VPN para amazon fire TV stick
Tipos de servicios web
A continuación se explican en detalle dos tipos de servicios web.
# 1) Servicio SOAP
El servicio SOAP significa Protocolo simple de acceso a objetos. Los servicios SOAP son servicios con estado que utilizan lenguaje XML para formar un sobre. Un sobre SOAP se puede describir en dos partes, es decir, una es Encabezado y cuerpo de SOAP , el otro es el protocolo utilizado para enviar mensajes SOAP.
Este encabezado SOAP consta de autenticación y autorización que otorga acceso. El cuerpo se incluye en la sección de carga útil de la solicitud que utiliza WSDL para describir el servicio web y el protocolo es principalmente HTTP (Protocolo de transmisión de hipertexto).
Seguridad de los servicios web
Los servicios SOAP tienen una capa SSL (Secure Socket Layer) que se encarga de evitar cualquier fuga de datos durante la transmisión, y por lo tanto proporciona cifrado y descifrado.
Mientras tanto, los servicios SOAP son más seguros ya que también cuenta con WSS (Web Services Security) que garantiza que no se divulgue durante la comunicación entre el servicio y la aplicación.
Como todos sabemos, todo Servicio Web (a diferencia de Web API), necesita una red para realizar su funcionamiento. Por lo tanto, es necesario que los servicios web brinden seguridad cuando se conectan a una red. Por lo tanto, Web Services tiene tres entidades importantes para cubrir el factor de seguridad durante la transferencia de mensajes.
- Autenticacion y autorizacion (Ya explicado arriba).
- Confidencialidad: Esto depende totalmente del SSL que proporciona cifrado y descifrado del sobre SOAP.
- Seguridad de la red: Esto significa extraer todas las respuestas SOAP y XML - RPC que obtiene del servidor. Por ejemplo, Si toma cualquier herramienta de servicio web como POSTMAN o PARASOFT, encontrará que debajo del administrador de encabezado HTTP, hay una opción para establecer el valor del tipo de contenido. El valor se puede establecer en la aplicación / JSON para que extraiga todos los REST (dado que los servicios SOAP no admiten las opciones del administrador de encabezados HTTP). Por lo tanto, puede pasar el tipo de contenido: Aplicación / XML en un carga útil sí mismo en forma de XML. Esto también extraería SOAP y XML-RPC.
Estos tres factores constituyen la seguridad de los servicios web para hacer frente a los ataques externos.
La arquitectura del servicio SOAP
Cada servicio SOAP depende de tres entidades que, en última instancia, forman la arquitectura del servicio SOAP.
- Proveedor de servicio: Todos los sistemas de software o aplicaciones que forman parte o proporcionan un servicio web.
- Solicitante del servicio: Todos los sistemas de software o aplicaciones que forman parte del servicio web de solicitudes del proveedor de servicios.
- Registro de servicios: Un registro o repositorio donde toda la información sobre el Servicio Web es proporcionada por el Proveedor de Servicios. (Ya discutido en UDDI)
Explicación
10 principales proveedores de servicios de seguridad gestionada
Estas tres entidades interactúan entre sí para llevar a cabo una Implementación exitosa del Servicio Web. Esto se hace en tres fases. La primera fase es la Publicar() fase en la que un proveedor de servicios proporciona todos los detalles sobre un servicio web en un registro o repositorio de servicios.
La segunda fase es Encontrar() donde una solicitud de servicio principalmente la aplicación cliente encuentra los detalles sobre el servicio web de un repositorio (también tiene archivo XML WSDL). La última fase es Vinculante() donde la aplicación cliente o el Solicitante del Servicio se sincroniza con el Proveedor del Servicio para la implementación final del Servicio Web.
# 2) Servicio RESTful
REST significa Transferencia de Estado Representacional, que es un Apátrida Servicio.
Se llama Stateless ya que el servidor web no almacena ninguna información sobre la sesión del cliente (tiempo de duración hasta que la aplicación del cliente está conectada y en ejecución), lo que significa que cada tipo de solicitud se trata y realiza fácilmente con la ayuda de métodos incorporados REST como GET, PUBLICAR, PERSONALIZAR (PONER), ELIMINAR, ENCABEZAR y así sucesivamente.
De hecho, estos métodos no están presentes en SOAP.
Método o verbos
Cada método en REST tiene su significado. A continuación se muestra la información sobre cada uno de ellos.
- OBTENER: Este método se utiliza para recuperar la información que se envía al servidor utilizando cualquiera de los métodos como PUT o POST. Este no tiene un cuerpo de solicitud. La ejecución exitosa le dará 200 objetos de respuesta.
- CORREO: Este método se usa para crear un documento o registro usando un cuerpo de solicitud, URL especificada, clave de documento, clave de contexto, etc. Lo mismo se puede recuperar usando el método GET. La ejecución exitosa le dará una respuesta 201.
- PONER: Esto está bajo la opción CUSTOM que está disponible en POSTMAN o PARASOFT. Este método se utiliza para actualizar cualquier documento o registro que ya esté presente. La ejecución exitosa le dará una respuesta de 201 o 200.
- ELIMINAR: Este método se utiliza para eliminar cualquier registro. La ejecución exitosa le dará una respuesta 204 (sin contenido).
Nota: Los códigos de respuesta HTTP dependen de cómo codifican los desarrolladores y, en ocasiones, pueden manipularse. Hemos enumerado los códigos de respuesta comunes que obtenemos de cada tipo de método.
La arquitectura del servicio REST
La arquitectura del servicio REST depende de dos entidades, es decir, el consumidor o solicitante del servicio y el proveedor del servicio. El consumidor del servicio es el que hace uso del servicio web y el proveedor de servicios es la colección de software o sistema que proporciona el servicio web.
La aplicación cliente, que normalmente es un consumidor de servicios, utiliza métodos incorporados de REST, una URL o URI, una versión HTTP y una carga útil (si el método lo admite).
JABÓN vs REST
Aunque estos dos tipos de servicios web se utilizan para llevar a cabo la solicitud y la respuesta, son completamente diferentes en la forma en que operan.
Sus diferencias se enumeran a continuación para su referencia.
- El sobre SOAP se puede utilizar en REST pero no al revés. P.ej. Un token de usuario que se crea en SOAP se puede pasar en la solicitud REST en el administrador de encabezados HTTP -> Autorización.
- SOAP suele ser más seguro que los servicios REST, ya que los servicios SOAP proporcionan WSS además de SSL. Este SSL está presente tanto en SOAP como en REST.
- SOAP es más lento que REST ya que el procesamiento de la solicitud lleva más tiempo en SOAP debido al formato de datos XML. REST usa JSON, que es muy ligero y, por lo tanto, lo hace más rápido.
- SOAP no tiene ningún método incorporado, pero REST tiene GET, PUT, POST, etc.
- SOAP tiene estado, mientras que REST no tiene estado.
- Los cuerpos de solicitud y respuesta en SOAP solo admiten el formato de datos XML. En REST, los cuerpos de solicitud y respuesta admiten muchos formatos de datos como JSON, XML, texto sin formato, etc.
Conclusión
Este tutorial de servicios web explica la arquitectura, los componentes y los tipos de servicios web.
También aprendimos sobre las diferencias entre los servicios SOAP y REST, junto con otros conceptos y terminologías importantes relacionados con los servicios web.
¡Esperamos que este tutorial le haya ayudado a comprender los servicios web!
PREV Tutorial | SIGUIENTE Tutorial
Lectura recomendada
- Tutorial de Python DateTime con ejemplos
- Tutorial de Java SWING: contenedor, componentes y manejo de eventos
- Tutorial de inyección de HTML: tipos y prevención con ejemplos
- Tutorial de secuencias de comandos de shell de Unix con ejemplos
- Tutorial de búsqueda de elementos por texto de selenio con ejemplos
- Tutorial de la función principal de Python con ejemplos prácticos
- Tutorial de pruebas por pares o pruebas de todos los pares con herramientas y ejemplos
- Tutorial de pruebas de configuración con ejemplos