Desarrollo de Sistemas Distribuidos: REST & SOAP

Buenos días esta vez comentaré acerca de SOAP( creado por Microsoft, IBM y otros y está actualmente bajo el auspicio de la W3C) y REST (creado por Roy Fielding), los conceptos generales desarrollados a lo largo del curso.

REST(Representational State Transfer)

Es un estilo de arquitectura de software para sistemas distribuidos tales como la web, a diferencia de SOAP, se centra en el uso de los estándares HTTP y XML para la transmisión de datos sin la necesidad de contar con una capa adicional. Las operaciones( o funciones) se solicitarán mediante GET, POST, PUT y DELETE, por lo que no requiere de implementaciones especiales para consumir estos servicios. Además se podrá utilizar JSON en vez de XML como contenedor de la información, por lo que será aconsejable utilizar este protocolo cuando busquemos mejorar el rendimiento, o cuando disponemos de escasos recursos, como sería el caso de los dispositivos móviles.

Características principales:

Ventajas

Bastante escalable (Más eficiente, más ligero)
Se centra en el uso de los estándares HTTP y XML para la transmisión de datos sin la necesidad de contar con una capa adicional.
Las operaciones (o funciones) se solicitan principalmente mediante GET, POST, PUT y DELETE, por lo que no requiere de implementaciones especiales para consumir estos servicios.
Elimina la necesidad de sincronizar datos de sesión con una aplicación externa. Lo que mejora el rendimiento.
Al exponer a sus métodos como URIs, REST se convierte en intuitivo para el consumo de estos servicios.
Se refleja el estado actual de un recurso y sus atributos, en el momento que alguna aplicación los requiere.
Más simple para desarrollar y esta opta por la preferencia de los programadores.

Desventajas

La principal desventaja de REST es que no puede ser utilizado en situaciones que exijan mantener el estado de un servicio o información de contexto.
Carece de estándares de seguridad, mensajería, políticas, etc.

Principios:

1. Sintaxis universal para identificar recursos (Identificador único URI)

Todo lo que debe ser identificado, por supuesto, debe tener un ID - En la Web, hay un concepto unificado para los números de identificación: La URI. URI comprende un espacio de nombres global, y utilizando URI's para identificar sus recursos clave significa tener un ID único y global.

2. Interfaz de operaciones bien definidas y uniforme (API Estandarizada)

Los métodos HTTP más importantes son PUT, GET, POST y DELETE. Ellos suelen ser comparados con las operaciones asociadas a la tecnología de base de datos, operaciones CRUD: CREATE, READ, UPDATE, DELETE. Otras analogías pueden también ser hechas como con el concepto de copiar-y-pegar (Copy&Paste). Todas las analogías se representan en la siguiente tabla:

Las acciones (verbos) CRUD se diseñaron para operar con datos atómicos dentro del contexto de una transacción con la base de datos. REST se diseña alrededor de transferencias atómicas de un estado más complejo, tal que puede ser visto como la transferencia de un documento estructurado de una aplicación a otra.

Recordemos que cuando utilizamos REST, HTTP no tiene estado. Cada mensaje contiene toda la información necesaria para comprender la petición cuando se combina el estado en el recurso. Como resultado, ni el cliente ni el servidor necesita mantener ningún estado en la comunicación. Cualquier estado mantenido por el servidor debe ser modelado como un recurso.

3. Comunicaciones sin guardar Estado (No estado HTTP)

Es importante señalar que, aunque REST incluiya la idea de "no mantener", eso no significa que la aplicación que exponga sus funcionalidades no pueda tener estado -de hecho, esto haría que el enfoque sea inútil en la mayoría de los escenarios. REST exige que el estado sea transformado en estado del recurso y sea mantenido en el cliente. En otras palabras, un servidor no debería guardar el estado de la comunicación de cualquiera de los clientes que se comunican con él más allá de una petición única. La razón más obvia de esto es la escalabilidad - el número de clientes que pueden interactuar con el servidor se vería significativamente afectada si fuera necesario mantener el estado del cliente.

4. Múltiples representaciones por hipermedias y utilización de hipervínculos. (Representación de estado OUT)

Tanto para la información de la aplicación como para las transiciones de estado de la aplicación: la representación de este estado en un sistema REST son típicamente HTML o XML. Como resultado de esto, es posible navegar de un recurso REST a muchos otros, simplemente siguiendo enlaces sin requerir el uso de registros u otra infraestructura adicional.

RESTFUL: Será RestFul si sigue los cuatro principios

SOAP(Simple Object Access Protocol)

Es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambios de datos XML, el punto identificativo de SOAP es que las operaciones son definidas como puertos WSDL (Web Services Description Language). Es por esto que será aconsejable utilizar este protocolo en entornos donde se establecerá un contrato formal y donde se describirán todas las funciones de la interfaz así como el tipo de datos utilizados tanto de entrada como de salida.

Estructura: Envelope , Header, Body

Carácterísticas:

Trabaja como nexo entre una aplicación y otra.
No es necesario saber el lenguaje en que trabajan las otras computadoras.
Las computadoras integrantes pueden tener diferentes sistemas operativos y pueden estar en distintas partes del mundo.
Puede tomar información de distintos sitios web.
Trabaja bien con datos, los mensajes y las comunicaciones están bien estructurados.
Dispone de proxys.
Funciona sobre diferentes protocolos, no solamente HTTP (como en REST) si no también sobre TCP, NamedPipes, MSMQ, etc. aunque el uso de estos no es tan bueno si se trata de estandarizar en Internet.

Ventajas

Fácil acceso, Simplicidad con respectos a otros, Es accesible a través de internet, Es independiente del sistema operativo, Se puede utilizar cualquier lenguaje
Tiene una Suites de estándares WS-* Como por ejemplo:

WSDL 2.0: Lenguaje de descripción de Servicios Web (W3C).
WS-BPEL 2.0: Web Services Business Process Execution Language versión 2.0. Especificación para estandarizar la representación y procesamiento de procesos de negocio (OASIS).
WS-Policy & WS-PolicyAttachment: Estándares que especifican un entorno general para definir la calidad de servicio y otras políticas asociadas con las comunicaciones de servicios Web y para asociar las políticas a objetivos específicos.
WS-SecurityPolicy: Especificación que describe las políticas de seguridad para los servicios Web.
WS-Security: Web Services Security Specification. Es un protocolo de comunicaciones que suministra un medio para aplicar seguridad a los servicios Web, incluidos la autenticación, autorización y privacidad. Es una especificación OASIS.