Tema 35: Aplicaciones web y seguridad: estándares, interoperabilidad y servicios web

Servicios web SOAP

Un servicio web es un conjunto de métodos y estándares que permite que aplicaciones heterogéneas se comuniquen entre sí a través de Internet, con independencia de la plataforma y del lenguaje de programación. Los servicios web clásicos («big web services») se apoyan en una pila de estándares basados en texto y XML: SOAP para el transporte de mensajes, WSDL para describir la interfaz y UDDI para publicar y localizar servicios. El uso de estándares basados en texto aporta la ventaja de la legibilidad e interoperabilidad, pero supone un inconveniente de rendimiento, ya que obliga a convertir los datos primitivos a texto y a validar y parsear documentos XML.

SOA: arquitectura orientada a servicios

La arquitectura orientada a servicios (SOA) es un modelo orientado a la reutilización de los servicios en entornos de sistemas distribuidos, que permite crear servicios de datos escalables y flexibles. Sus elementos esenciales se articulan en tres funciones o actores:

• Proveedor de servicios (service provider): publica e implementa el servicio.

• Agente o registro de servicios (service registry/broker): actúa como directorio para localizar las funcionalidades disponibles en la red.

• Usuario o consumidor del servicio (service requester): quien lo busca e invoca.

SOAP representa la principal forma de comunicación entre estos tres actores clave de una SOA. Conviene recordar que SOA no se implementa con HTML5, CSS3 y JavaScript (eso corresponde al front-end web, no a la integración de servicios): su propósito es facilitar la integración de servicios empresariales.

El protocolo SOAP

SOAP (Simple Object Access Protocol) es un protocolo estándar, y una recomendación del W3C, que define cómo dos objetos situados en procesos diferentes pueden comunicarse mediante el intercambio de datos XML. Es una especificación para el intercambio de información estructurada en un entorno distribuido y descentralizado, cuyo propósito principal es intercambiar información entre aplicaciones.

Estructura del mensaje SOAP

Un mensaje SOAP se compone de tres partes bien definidas:

El Header es el elemento opcional; si aparece, debe ser el primer hijo del Envelope. El Web Service Listener es el componente que recibe y envía los mensajes en formato SOAP entre el consumidor y el proveedor.

WSDL: descripción del servicio

WSDL (Web Services Description Language) es un lenguaje XML, recomendación del W3C, para describir servicios web: es el estándar básico donde se describen los formatos y requisitos del mensaje necesarios para interactuar con el servicio, especificando su interfaz. WSDL 2.0 permite describir el servicio a partir de un modelo abstracto de lo que ofrece. Sus elementos principales son:

• <types>: define los tipos de datos (esquema XML) que utiliza el servicio.

• <interface> (WSDL 2.0; portType en WSDL 1.1): describe las operaciones abstractas.

• <binding>: define el protocolo y el formato de los datos para cada tipo de puerto.

• <service>: agrupa los puntos de acceso (endpoints).

WSDL no tiene por objetivo definir un alojamiento (hosting) para los servicios web, ni recoge el «enlace lógico con la implementación concreta» como elemento propio de su descripción.

UDDI, WS-I y seguridad

• UDDI (Universal Description, Discovery and Integration) es un servicio de registro y directorio de servicios web, en XML, donde un proveedor publica su servicio y un consumidor lo busca. Es un estándar de OASIS.

• WS-I (Web Services Interoperability Organization) es una organización independiente creada para fomentar la interoperabilidad de los servicios web sobre cualquier plataforma, sistema operativo y lenguaje (perfiles Basic Profile).

• SAML (Security Assertion Markup Language) es un estándar abierto que define un esquema XML para el intercambio de datos de autenticación y autorización; se emplea como elemento de seguridad en los servicios web.

Las organizaciones responsables de la arquitectura y reglamentación de los servicios web son OASIS y W3C. Entre los estándares del W3C se cuentan SOAP y WSDL; el propósito de la arquitectura de servicios web según el W3C es facilitar la comunicación entre el proveedor y el consumidor de servicios.

Implementaciones Java: JAX-RPC, JAX-WS, Axis y CXF

• JAX-RPC proporciona las API básicas para el desarrollo y despliegue de servicios web en la plataforma Java (Java EE), con el fin de desarrollar servicios web interoperables.

• JAX-WS es el modelo de programación de próxima generación que complementa a JAX-RPC, ofreciendo mayor independencia de plataforma.

• Apache Axis es un framework de código abierto basado en XML para desplegar aplicaciones de servicios web; es un motor nuclear de servicios web.

• Apache CXF es un framework completo de código abierto para servicios web y la librería utilizada para implementar la API Java JAX-WS.

XML, DTD, XML Schema, DOM/SAX y XPath

XML reduce el tiempo de desarrollo al facilitar la representación de datos con una tecnología sencilla y conocida, aunque su rendimiento se ve penalizado por la conversión de datos primitivos a texto y por la validación y el parseo.

• DTD (Document Type Definition): define la estructura de elementos de un documento XML. Un DTD externo se invoca con <!DOCTYPE archivoExterno SYSTEM "archivoExterno.dtd">. Sus componentes son Elements, Attributes, Entities, PCDATA y CDATA.

• XML Schema: para un elemento opcional y sin límite de ocurrencias se usa <xs:element name="description" type="xs:string" minOccurs="0" maxOccurs="unbounded" />.

• DOM vs SAX: DOM lee el documento y construye un árbol en memoria con toda su estructura; SAX es un parser basado en eventos que no construye ese árbol (por eso es falso atribuir a SAX la construcción del árbol en memoria).

• XPath: lenguaje que permite construir expresiones que recorren y procesan un documento XML (p. ej. /Usuarios/usuario[numIntentos>3]/apellidos). Sintaxis típica: //nombreEtiqueta[@atributo='valor']. Distingue XPath absoluto (ruta directa desde la raíz) y relativo (desde un punto intermedio del DOM). No permite «cambiar la ruta» del elemento.

• XHTML: todos los valores de los atributos deben ir entre comillas, sin excepción para los numéricos.

Fuentes

• W3C — SOAP Version 1.2 Part 1: Messaging Framework: https://www.w3.org/TR/soap12-part1/

• W3C — SOAP Version 1.2 Part 0: Primer: https://www.w3.org/TR/soap12-part0/

• W3C — WSDL Version 2.0 Part 1: Core Language: https://www.w3.org/TR/wsdl20/

• W3C — WSDL 2.0 Part 0: Primer: https://www.w3.org/TR/2007/REC-wsdl20-primer-20070626/

• OASIS — UDDI Specification: https://www.oasis-open.org/committees/uddi-spec/

• OASIS — SAML (Security Services TC): https://www.oasis-open.org/committees/security/

• OASIS — WS-I Member Section: https://www.oasis-open.org/2017/12/21/oasis-announces-successful-completion-of-web-services-interoperability-ws-i-member-section/

• W3C — XML 1.0 y XPath: https://www.w3.org/TR/xml/ y https://www.w3.org/TR/xpath-31/

• W3C — XML Schema: https://www.w3.org/TR/xmlschema11-1/

• Oracle — SOA and Web Services (JAX-RPC/JAX-WS): https://www.oracle.com/technical-resources/articles/javase/webservices-protocols.html

• Apache CXF: https://cxf.apache.org/ · Apache Axis: https://axis.apache.org/

Servicios web REST y APIs

REST (Representational State Transfer, Transferencia de Estado Representacional) es un estilo de arquitectura para sistemas distribuidos definido por Roy Fielding en su tesis doctoral (2000). No es un protocolo ni un estándar oficial, sino un conjunto de principios de diseño para construir servicios web sobre el protocolo de aplicación HTTP. Un servicio o API que cumple estos principios se denomina RESTful. En este contexto, REST es una definición de arquitectura para el intercambio y manejo de datos a través de servicios web y, a la vez, una interfaz para conectar sistemas basada en HTTP: cuando se necesita conectar sistemas basados en HTTP, la respuesta natural es una interfaz REST.

El papel de una API REST

Una API REST actúa como capa que almacena y gestiona la lógica de negocio y sirve datos a través de recursos identificados por URL. Cada entidad del sistema (un usuario, un pedido, un documento) es un recurso con su propia URL, y el cliente opera sobre él mediante los métodos del protocolo HTTP. Su funcionamiento se basa íntegramente en HTTP, lo que la convierte en su característica más distintiva.

Restricciones arquitectónicas

Las propiedades fundamentales de REST son:

• Cliente-servidor: REST separa cliente y servidor, de modo que ambos evolucionan de forma independiente. El cliente no necesita conocer la implementación interna del servidor y viceversa; esta separación de responsabilidades es una de sus ventajas principales.

• Sin estado (stateless): el servicio no almacena información sobre el estado del cliente entre peticiones. Cada solicitud debe contener toda la información necesaria para ser procesada. Por ello es INCORRECTO afirmar que REST es un protocolo cliente/servidor con estado: precisamente es sin estado.

• Cacheable, sistema en capas e interfaz uniforme completan el conjunto de restricciones.

Métodos (verbos) HTTP

REST utiliza los métodos (verbos) estándar de HTTP para realizar operaciones. Los cuatro más habituales, asociados al patrón CRUD, son GET, POST, PUT y DELETE:

Según RFC 9110, HEAD es idéntico a GET salvo que el servidor no debe enviar contenido en el cuerpo, y TRACE realiza una prueba de bucle de mensaje (message loop-back) a lo largo del camino al recurso objetivo, lo que permite depurar la ruta. PATCH (RFC 5789) se distingue de PUT en que aplica modificaciones parciales en lugar de sustituir el recurso entero.

Conviene recordar que Send NO es un método HTTP soportado por una API REST: no existe tal verbo en la especificación.

Paso de parámetros con GET

Con el método GET, las variables se concatenan en la cadena de consulta de la URL. Tras el interrogante ? se colocan pares clave=valor unidos por el carácter &. Ejemplo correcto:

http://www.opositatest.com/index.php?page=mia&variable2=valor2&variable3=valor3

Sobre GET y POST, es INCORRECTA la afirmación de que «el método GET no permite almacenamiento en la memoria caché»: precisamente las respuestas a GET sí son cacheables, a diferencia de POST.

Códigos de estado HTTP

La API comunica el resultado mediante códigos de estado. Los más relevantes para una API RESTful son:

• 400 Bad Request: el servidor no puede procesar la petición por un error del cliente; p. ej., un POST que espera ciertos parámetros vía JSON pero recibe otros distintos.

• 403 Forbidden: el servidor entiende la petición pero rechaza otorgar respuesta porque el cliente no posee los permisos necesarios.

• 404 Not Found: el servidor no pudo encontrar el contenido solicitado.

Formato de datos: JSON frente a XML

Actualmente el formato de datos más utilizado en REST es JSON (JavaScript Object Notation), por ser más ligero (liviano) y legible (fácil de leer) que XML, lo que mejora especialmente el rendimiento en aplicaciones móviles. REST admite tanto XML como JSON.

REST frente a SOAP

Una diferencia principal es que SOAP es más complejo y solo trabaja con XML, mientras que REST es más sencillo y trabaja con XML y JSON. Frente a SOAP, REST ofrece mejor rendimiento y ligereza, especialmente en aplicaciones móviles. Su principal desventaja es que no existe un estándar oficial que imponga cómo realizar los métodos HTTP: REST usa métodos HTTP estándar pero no impone reglas estrictas sobre cómo aplicarlos, lo que puede generar inconsistencias entre implementaciones.

Además, NO es característica de los servicios REST usar la especificación UDDI para publicar y localizar servicios web: UDDI pertenece al mundo de los servicios web SOAP/WSDL, no a REST.

Arquitectura sin servidor (serverless)

Complementariamente, la arquitectura sin servidor (serverless) es un modelo de computación donde el proveedor del cloud gestiona la infraestructura de servidor, y los desarrolladores solo necesitan preocuparse por el código de su aplicación. Es un modelo habitual para desplegar APIs REST sin administrar máquinas.

Fuentes

• IETF, RFC 9110 HTTP Semantics (métodos GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE y códigos de estado 400/403/404): https://www.rfc-editor.org/rfc/rfc9110.html

• IETF, RFC 5789 PATCH Method for HTTP: https://www.rfc-editor.org/rfc/rfc5789.html

• R. T. Fielding, Architectural Styles and the Design of Network-based Software Architectures (tesis, capítulo 5: REST): https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

• MDN Web Docs, HTTP request methods (W3C/WHATWG referencia): https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods