Tema 21 Desarrollo Web III REST y SOAP.docx

**Tema 21 Desarrollo Web III: SOAP y REST.** (\*) Los términos servicio web y API se usan indistintamente. Sin embargo, las API son la categoría más amplia. Los servicios web son un tipo especial de API. (\*) Tanto SOAP como REST permiten la comunicación síncrona. Desde que REST salió a la luz, s...

**Tema 21 Desarrollo Web III: SOAP y REST.** (\*) Los términos servicio web y API se usan indistintamente. Sin embargo, las API son la categoría más amplia. Los servicios web son un tipo especial de API. (\*) Tanto SOAP como REST permiten la comunicación síncrona. Desde que REST salió a la luz, siempre ha habido un debate en torno a su comparación con SOAP. REST fue rápidamente catalogado como alternativa a SOAP. Aun así, actualmente SOAP todavía posee el monopolio en el mundo de los Servicios Web. Ambos difieren en muchos aspectos comenzando por que REST fue concebido en el ámbito académico y SOAP es un estándar de la industria, creado por un consorcio del cual Microsoft formaba parte. Las principales diferencias en el funcionamiento de ambos son: - SOAP es un protocolo orientado a RPC (Llamada a procedimiento remoto), mientras que para REST solamente existen los métodos de HTTP y está orientado a recursos. - REST no permite el uso estricto de "sesión" puesto que por definición es sin estado, mientras que para SOAP, al ser orientado a RPC, los servicios Web crean sesiones para invocar a los métodos remotos. - SOAP utiliza HTTP como un túnel por el que pasa sus mensajes, se vale de XML para encapsular datos y funciones en los mensajes. Si dibujásemos una pila de protocolos, SOAP iría justo encima de HTTP, mientras que REST propone HTTP como nivel de aplicación. **REST** **REST (Representational state transfer) es una arquitectura para el diseño de APIs sobre el protocolo HTTP. La arquitectura del estilo REST principalmente define reglas, comportamiento y restricciones sobre el funcionamiento de una API. Mencionando que, todas las APIs que siguen esta arquitectura son conocidas o llamadas como "API RESTful".** **La construcción y diseño de REST se basa en los siguientes principios descritos a continuación:** - [Cliente-servidor]**: El cliente y el servidor deben estar completamente separados e independientes. La única forma de comunicación debe ser mediante solicitudes HTTP. Separar lo que es competencia del cliente y el servidor es el principio de todo. Hay que distinguir lo que concierne al interfaz del usuario del almacenamiento de datos.** - [Sin estado (stateless)]**: La comunicación entre el cliente y el servidor debe ser sin estado, lo cual implica que no se almacenará ni se compartirá información entre peticiones. Toda petición es independiente y debe contener sólo la información necesaria para procesarla.** **Cada petición del cliente debe contener toda la información necesaria para que el servidor la comprenda y no necesite mirar ningún dato almacenado previamente sobre el contexto de la comunicación. El estado de la sesión por lo tanto se guarda íntegramente en el cliente.** - **[Posible uso de Cache]: Las respuestas a una petición deben poder ser etiquetadas como cacheable o nocacheable. Si una respuesta es cacheable, entonces el cliente puede almacenar en memoria cache esa respuesta que más tarde podrá hacer uso de ella.** **La ventaja de añadir esta restricción es que se evitarán determinadas peticiones al servidor y se va a reducir el tiempo medio de espera de una serie de interacciones.** **La desventaja de esta restricción es que puede inducir a un mal funcionamiento de una aplicación si los datos obtenidos del caché difieren de los que se hubiesen obtenido realizando la petición directamente al servidor.** - **[Sistema por capas]: En una arquitectura de sistema por capas, el cliente puede conectarse con otros intermediarios autorizados entre el cliente y el servidor y todavía recibirá respuestas del servidor. Los servidores también pueden pasar las solicitudes a otros servidores. Es posible diseñar el servicio web RESTful para que se ejecute en varios servidores con múltiples capas, como la seguridad, la base de datos y la lógica empresarial, que trabajan juntas para cumplir las solicitudes de los clientes. Estas capas se mantienen invisibles para el cliente.** - **[Orientada a recurso]: Los recursos son la información que diferentes aplicaciones proporcionan a sus clientes. Los recursos pueden ser imágenes, videos, texto, números o cualquier tipo de datos.** **El servidor identifica cada recurso con identificadores únicos de recursos (URI).** **Cuando un usuario desea realizar una actividad remota, no accederá a un Servicio directamente, sino que accederá a un recurso o mejor dicho a la representación de ese recurso. Por ejemplo, un usuario quiere conocer el saldo que tiene en su cuenta bancaria. Según el estilo REST, para realizar esta acción, el usuario no accederá directamente a un método que le proporcione la información de la cuenta, sino que accederá a la representación del recurso que contiene el saldo de su propia cuenta bancaria. Como vemos, REST tiene una visión de los Servicios Web en la que sustituye métodos remotos por acceso a recursos remotos.** **Cada recurso estará representado por XML, JSON, HTML,...** - **[Uso correcto de HTTP]: REST debe respetar tanto los métodos y códigos de estado para cada operación (GET, POST, PUT, DELETE, etc.).** - **[Uso correcto de métodos en las peticiones y código de estado HTTP de las respuestas]** - - - - - - - - - - - - - - - - - **[Uso de sustantivos en endpoints y nombres en plural]** **En el correcto diseño de una API del estilo REST, se considera utilizar sustantivos y nombres en plural en nuestros endpoints y NO verbos de acción, esto es básicamente porqué la acción ya está determinada en los métodos de HTTP.** **Incorrecto ❌:** **POST https://api.com/v1/createUser** **Correcto ✔:** **POST [[https://api.com/v1/users]](https://api.com/v1/users)** **[Uso de parámetros para el filtrado].** **Para realizar las operaciones de filtrado en nuestra API REST, lo debemos hacer mediante Query Strings. Las Query Strings o cadenas de consultas son un término que se utiliza para hacer referencia a una interacción adicional sobre un recurso o base de datos.** **A continuación, algunas referencias y estandarizaciones para algunas acciones:** **Filtrado de recursos** **GET https://api.com/v1/users?first\_name=diego&last\_name=cortes** **Buscador de campos específicos** **GET [[https://api.com/v1/users?fields=first\_name,last\_name]](https://api.com/v1/users?fields=first_name,last_name)** **[Autenticación y autorización en API REST]** **La protección y el control de la información de los servicios es un requisito obligatorio a la hora de hacer públicos los servicios mediante una API o cualquier otro sistema. Se deberá añadir una capa de autenticación/autorización para ello.** **Los 4 métodos principales de autentificación API REST son:** - **Autentificación básica** - **Autentificación basada en token** - **Autentificación basada en clave API** - **OAuth 2.0 (Autorización abierta)** **[Ventajas de REST]** - **Escalabilidad:** - **REST optimiza las interacciones entre el cliente y el servidor.** - **La tecnología sin estado elimina la carga del servidor porque este no debe retener la información de solicitudes pasadas del cliente. Evita acoplamientos.** - **El almacenamiento en caché bien administrado elimina de forma parcial o total algunas interacciones entre el cliente y el servidor.** - **Flexibilidad:** - **Los servicios web RESTful admiten una separación total entre el cliente y el servidor.** - **Al poderse desacoplar varios componentes del servidor, cada parte podrá evolucionar de manera independiente. Los cambios de la plataforma o la tecnología en la aplicación del servidor no afectan la aplicación del cliente.** - **La capacidad de ordenar en capas las funciones de la aplicación aumenta la flexibilidad aún más. Por ejemplo, los desarrolladores pueden efectuar cambios en la capa de la base de datos sin tener que volver a escribir la lógica de la aplicación.** - **Independencia de tecnologías / lenguajes:** - **Puede escribir aplicaciones del lado del cliente y del servidor en diversos lenguajes de programación, sin afectar el diseño de la API.** - **También puede cambiar la tecnología subyacente en cualquiera de los lados sin que se vea afectada la comunicación.** **[Desventajas de REST]** - **En las API REST no se mantiene el estado esto puede empeorar el funcionamiento de la red porque incrementa el tráfico de datos repetidos al enviar una serie de peticiones. Esto ocurre porque los datos no pueden quedarse almacenados en el servidor identificando un contexto determinado de comunicación.** - **La posibilidad de utilizar caché y no hacerlo de forma adecuada puede inducir a un mal funcionamiento de una aplicación si los datos obtenidos del caché difieren de los que se hubiesen obtenido realizando la petición directamente al servidor.** - **La principal desventaja de los sistemas de capas es que añaden cabeceras y retrasos al procesamiento de datos.** - **Fiabilidad: REST requiere que se intente de nuevo la llamada en caso de errores de comunicación.** Texto Descripción generada automáticamente con confianza media **SOAP** SOAP (Simple Object Access Protocol), SOAP de forma resumida es un protocolo para acceder a los servicios web. Es un protocolo de comunicación basado en XML que permite la interoperabilidad fluida entre sistemas heterogéneos. En esencia, SOAP actúa como un mensajero universal, permitiendo que aplicaciones en distintos lenguajes y plataformas se intercambien información de manera estándar y estructurada. SOAP se transporta principalmente a través de HTTP pero también se puede transportar a través de otros protocolos como SMTP (protocolo para transferencia simple de correo) y FTP (protocolo de transferencia de archivos). SOAP es un protocolo orientado a RCP, lo que es lo mismo, el cliente se comunica con el servidor a través de llamadas a métodos remotos del servidor. [Modelo de procesamiento] SOAP provee un modelo de procesamiento distribuido en el que un mensaje es originado por un emisor inicial SOAP, y enviado a un receptor final SOAP a través de cero o más intermediarios SOAP. Este modelo puede soportar muchos Patrones de Intercambio de Mensajes o MEPs, incluyendo mensajes unidireccionales, interacciones del tipo petición/respuesta y conversaciones punto a punto. Este modelo especifica cómo un receptor SOAP procesa el mensaje que le ha llegado. En el modelo no está contemplado el mantener ningún estado en la comunicación, o el llevar un control de la correlación de los mensajes. Un nodo SOAP puede jugar uno o más roles SOAP en el procesamiento de mensajes. Cada uno de los roles SOAP se identifica mediante un URI conocida como nombre del rol SOAP. El rol que juega un nodo no puede variar a lo largo del procesamiento de un único mensaje SOAP. [Estructura del mensaje SOAP]  [Sobre o envelope] (SOAP-ENV:Envelope ) [ ] Es el elemento raíz de un mensaje SOAP y es obligatorio. En esta sección se especifica los espacios de nombres expresado en XML schema para definir los elementos y atributos válidos para el mensaje. Este atributo es obligatorio: *xmlns:SOAP-ENV=\"http://schemas.xmlsoap.org/soap/envelope/\"* luego se pueden referenciar más espacios de nombres. [Encabezado (SOAP-ENV:Header)] El encabezado SOAP es opcional y, permite añadir características a un mensaje SOAP. Puede contener diferentes bloques. También se pueden definir espacios de nombres. Un bloque de cabecera SOAP puede llevar un atributo llamado role, que se usa para apuntar a nodos SOAP que jueguen ese rol especificado. Si el rol especificado para el nodo coincide con el atributo role del bloque de cabecera, el nodo procesa la cabecera. Si el bloque de cabecera incluye un atributo \"mustUnderstand\" y tiene valor \"1\" o "true" se dice que el bloque de cabecera SOAP debe obligatoriamente ser procesado por ese nodo con ese mismo role especificado. Si tiene valor "0" o "false" podrá ser ignorado por el nodo. Sí uno o más bloques de cabecera SOAP no pueden ser comprendidos por el nodo, entonces se genera un fallo SOAP. Cuando un nodo intermedio procese un bloque de cabecera que apuntaba a él, lo deberá eliminar y no se retrasmitirá. Si el nodo intermediario ignoró el bloque de cabecera que apuntaba a él, lo deberá eliminar a no ser que el bloque esté marcado como "relay" a "1" o "true" que deberá retrasmitirlo. Atributo encodingStyle en SOAP 1.1 está presente en cualquier elemento. En SOAP 1.2 solo podrá estar presente en los bloques de las cabeceras y del cuerpo. El atributo encodingStyle indica las normas utilizadas para codificar las partes de un mensaje SOAP. No existe un formato de codificación por defecto, sino que existen una serie de posibles formatos a utilizar. El valor de este atributo es una lista ordenada de una o más URIs que identifican la regla o reglas de serialización que pueden ser utilizadas en el mensaje, en el orden en el que se han de aplicar. [Cuerpo (SOAP-ENV:Body)] El cuerpo SOAP es necesario y que contiene información destinada al destinatario final del mensaje. El elemento del cuerpo y sus elementos hijo asociados se utilizan para intercambiar información entre el remitente SOAP inicial y el destinatario SOAP final. SOAP define un elemento hijo para el cuerpo: el elemento \, que se utiliza para notificar errores. Otros elementos del cuerpo los define el servicio web que los utiliza. Cuando un receptor recibe un mensaje SOAP, deberá primero validar el documento y luego parsear el documento para extraer la información. \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-- Los proveedores publican en el registro los servicios que exponen utilizando el lenguaje de definición: WSDL, indicando su localización y describiendo su funcionamiento. Diagrama Descripción generada automáticamente [Seguridad con WS-Security] La meta de WS-Security es permitir que las aplicaciones construyan intercambios seguros de mensajes SOAP. Esta especificación está destinada a proporcionar un conjunto flexible de mecanismos que puedan ser utilizados para construir una amplia gama de protocolos de seguridad; en otras palabras, esta especificación intencionadamente no describe explícitamente protocolos de seguridad, sino que define las primitivas para poder hacerlo. Como con cualquier protocolo de seguridad, WS-Security por sí sólo no garantiza la seguridad y se debe aplicar un gran esfuerzo para garantizar que los protocolos de seguridad construidos con WS-Security no resulten vulnerables cuando se enfrentan a un amplio abanico de ataques. Como ya se ha dicho, el Lenguaje de Seguridad de Servicios Web (WS-Security) soporta una amplia variedad de modelos de seguridad. [Las características principales de SOAP son las siguientes]: - Formato del mensaje: SOAP utiliza XML (Extensible Markup Language) para estructurar y formatear los mensajes. Esto permite que los datos sean legibles tanto para humanos como para máquinas. - Mensaje estructurado: Un mensaje SOAP consta de una envoltura (envelope) que contiene el mensaje y su información asociada, como encabezados (headers) y el cuerpo (body) que contiene los datos del mensaje. - Protocolo basado en estándares: SOAP es un protocolo basado en estándares y es independiente de la plataforma, lo que significa que puede ser utilizado por diferentes sistemas operativos y lenguajes de programación. - Independiente del protocolo de aplicación subyacente: HTTP, SMTP, FTP, etc. Sin embargo, la implementación más común es sobre HTTP, utilizando las peticiones POST. - Seguridad: proporciona opciones para implementar medidas de seguridad como SSL/TLS para encriptar la comunicación. SSL es una tecnología estandarizada que permite cifrar el tráfico de datos entre un navegador web y un sitio web (o entre dos servidores web), protegiendo así la conexión. Para ello se utilizan certificados digitales. TLS es una versión actualizada y más segura de SSL. Si aparecen las letras HTTPS al principio de la dirección (URL) de un sitio web, dicho sitio está protegido por un certificado SSL o TLS. Además, en la barra de direcciones del navegador aparece un icono de un candado y, al hacer clic sobre ese icono, los usuarios pueden consultar los datos del certificado, como la autoridad emisora y el nombre de la empresa propietaria del sitio web. - WS- (Web Services): SOAP se utiliza comúnmente en la implementación de Web Services, que son servicios web que ofrecen una interfaz para la comunicación y la interacción entre aplicaciones. Ventajas de SOAP: - Estandarización: SOAP es un estándar reconocido a nivel internacional. - Interoperabilidad entre diferentes sistemas: - Es independiente de la plataforma y el lenguaje de programación - Tiene la capacidad de describir los servicios de manera formal utilizando el lenguaje de descripción de servicios web (WSDL). - Permite transacciones: lo que permite la ejecución de operaciones atómicas, consistentes, aisladas y duraderas (ACID) en sistemas distribuidos. - Soporte para diferentes protocolos de transporte: Aunque es más comúnmente utilizado sobre HTTP, SOAP no está limitado a un solo protocolo de transporte, lo que brinda flexibilidad en su implementación. - SOAP tiene una lógica de gestión de errores integrada y proporciona más fiabilidad que REST. Desventajas DE SOAP: - Complejidad y sobrecarga: SOAP utiliza XML para estructurar sus mensajes, lo que puede resultar en una sobrecarga significativa en comparación con otros formatos más ligeros, como JSON. Esto puede ralentizar la velocidad de transmisión de datos. Los mensajes SOAP suelen ser grandes, ya que deben contener la información que las aplicaciones y los clientes necesitan para analizar los datos que contienen y ejecutar la lógica apropiada. Cuanto más grande es el mensaje, más procesamiento requiere del servidor, lo que aumenta el consumo de recursos y disminuye la capacidad total (menor rendimiento). El aumento de tamaño también puede tener un efecto adverso sobre el rendimiento de aplicaciones desarrolladas sobre SOAP, ya que se necesitan más recursos de red para transferir los mensajes. SOAP generalmente tiene un rendimiento inferior en comparación con protocolos más ligeros como REST/JSON. - Rigidez: Las API de SOAP son rígidas y con una estructura para sus mensajes muy estrictas. - Escalabilidad: El protocolo SOAP requiere que las aplicaciones almacenen el estado entre las solicitudes, lo que aumenta los requisitos de ancho de banda y memoria. Como resultado, hace que las aplicaciones sean costosas y difíciles de escalar. A diferencia de SOAP, REST permite una arquitectura sin estado y en capas, lo que la hace más escalable. Por ejemplo, el servidor de aplicaciones puede pasar la solicitud a otros servidores o permitir que un intermediario (como una red de entrega de contenido) la gestione. - Falta de soporte en navegadores web: A diferencia de REST/JSON, SOAP no es compatible con navegadores web directamente, lo que puede limitar su utilidad para ciertas aplicaciones web y móviles. - Menor adopción en entornos modernos: Con el surgimiento de RESTful APIs y protocolos más ligeros, SOAP ha perdido popularidad en aplicaciones web y móviles modernas, aunque sigue siendo relevante en entornos empresariales más tradicionales.