UNIVERSIDAD DE SEVILLA

INGENIERIA SUPERIOR DE TELECOMUNICACIONES

PROYECTO FIN DE CARRERA

Representational State Transfer (REST). Un estilo de arquitectura para Servicios Web. Panorámica y estado del arte.

Realizado por:

Tutor del proyecto: Antonio J. Sierra Collado

Alumno: Alberto Cubo Velázquez

INDICE DE CONTENIDOS

1 OBJETIVOS............................................................................................................102 INTRODUCCIÓN...................................................................................................11

2.1 Temática de los capítulos................................................................................123 CONCEPTOS PREVIOS........................................................................................14

3.1 URL.................................................................................................................143.1.1 Sintaxis....................................................................................................153.1.2 URI y Referencias URI...........................................................................173.1.3 Diferenciación entre mayúsculas/minúsculas..........................................193.1.4 URLs en el uso diario..............................................................................193.1.5 El gran marco..........................................................................................20

3.2 UUID...............................................................................................................213.3 HTTP...............................................................................................................21

3.3.1 Características y funcionamiento............................................................213.3.2 Comandos del protocolo HTTP...............................................................24

3.4 XML................................................................................................................293.4.1 Conceptos básicos...................................................................................303.4.2 DTD: Definición de Tipos de Documentos.............................................323.4.3 Entidades.................................................................................................363.4.4 Modelo de Objetos de Documentos: DOM.............................................37

3.5 Conclusiones....................................................................................................384 SOAP Y WSDL.......................................................................................................39

4.1 SOAP...............................................................................................................394.1.1 Concepto de SOAP..................................................................................394.1.2 Objetivos de SOAP..................................................................................404.1.3 Un ejemplo sencillo de mensajes SOAP.................................................414.1.4 Serialización............................................................................................434.1.5 Protocolo HTTP mediante SOAP............................................................46

4.2 WSDL..............................................................................................................484.3 Conclusiones....................................................................................................52

5 REPRESENTATIONAL STATE TRANSFER: REST..........................................535.1 Introducción.....................................................................................................535.2 Origen de REST, Roy Thomas Fielding..........................................................545.3 Objetivos..........................................................................................................555.4 Restricciones de REST....................................................................................55

5.4.1 Cliente-Servidor......................................................................................555.4.2 Sin estado (Stateless)...............................................................................565.4.3 Caché.......................................................................................................575.4.4 Interfaz uniforme.....................................................................................585.4.5 Sistema de capas......................................................................................585.4.6 Código bajo demanda..............................................................................59

5.5 Elementos arquitectónicos de REST...............................................................595.5.1 Datos en REST........................................................................................595.5.2 Conectores en REST................................................................................645.5.3 Componentes en REST............................................................................67

5.6 Vistas de la arquitectura REST........................................................................685.6.1 Vista de proceso......................................................................................68

5.6.2 Vista de conector.....................................................................................705.6.3 Vista de datos..........................................................................................71

5.7 HTTP, URI y XML en REST.........................................................................735.7.1 Estandarizando la Web............................................................................735.7.2 REST aplicado a URI..............................................................................745.7.3 REST aplicado a HTTP...........................................................................795.7.4 REST y XML..........................................................................................875.7.5 Repercusiones de usar HTTP y URI.......................................................88

5.8 Cuestiones por resolver...................................................................................885.8.1 David Megginson....................................................................................895.8.2 ebPML.org...............................................................................................98

5.9 Conclusiones....................................................................................................996 DEBATE REST-SOAP.........................................................................................100

6.1 PAUL PRESCOD..........................................................................................1016.1.1 Raíces del debate REST-SOAP [14].....................................................1016.1.2 Algunos pensamientos sobre la seguridad de REST-SOAP [15]..........109

6.2 ROBERT McMILLAN.................................................................................1126.2.1 REST, sustituto de SOAP-RPC [16].....................................................1126.2.2 Una aproximación a los Servicios Web basada en REST [17].............113

6.3 ROY HOOBLER...........................................................................................1156.3.1 REST puede acabar con SOAP [18]......................................................115

6.4 AMIT ASARAVALA...................................................................................1176.4.1 Dando un descanso (REST) a SOAP [19].............................................118

6.5 SAM RUBY..................................................................................................1206.5.1 REST + SOAP [20]...............................................................................120

6.6 TIM BRAY....................................................................................................1216.6.1 The SOAP/XML-RPC/REST SAGA [21]............................................121

6.7 BENJAMIN CARLYLE...............................................................................1246.7.1 REST vs Orientación a Objetos [22].....................................................124

6.8 Disenchanted dictionary................................................................................1276.8.1 REST [23].............................................................................................127

6.9 Conclusiones..................................................................................................1297 IMPLEMENTACIONES......................................................................................130

7.1 Implementaciones REST en la Web..............................................................1307.1.1 Amazon..................................................................................................1307.1.2 eBay.......................................................................................................1317.1.3 Restlets..................................................................................................131

7.2 Ejemplo de uso de REST...............................................................................1327.2.1 Conseguir una lista de las partes..........................................................1337.2.2 Conseguir datos detallados de una parte...............................................1337.2.3 Emitir una PO (orden de compra).........................................................134

7.3 Errores comunes a la hora de diseñar con REST..........................................1347.4 Conclusiones..................................................................................................137

8 EVOLUCIÓN Y FUTURO DE REST..................................................................1388.1 Progresión de REST......................................................................................1388.2 Futuro de REST según Paul Prescod.............................................................1398.3 Reflexión personal sobre el futuro de REST.................................................141

9 TEMPORIZACIÓN Y PRESUPUESTO..............................................................1429.1 Temporización...............................................................................................1429.2 Presupuesto....................................................................................................143

9.2.1 Costes de personal.................................................................................1439.2.2 Costes de Software................................................................................1439.2.3 Costes de Hardware...............................................................................1449.2.4 Otros costes...........................................................................................1449.2.5 Resumen presupuestario........................................................................144

10 BIBLIOGRAFÍA:..............................................................................................14610.1 Bibliografía procedente de la Web................................................................14610.2 Especificaciones consultadas.........................................................................14710.3 Bibliografía procedente de libros..................................................................148

INDICE DE FIGURAS

Figura 1: Servicios Web..................................................................................................12Figura 2: URI-URL.........................................................................................................18Figura 3: Petición HTTP.................................................................................................23Figura 4: Mensaje HTTP para solicitud/respuesta..........................................................24Figura 5: Jerarquía del documento ejemplo XML..........................................................34Figura 6: Ejemplo de uso de SOAP.................................................................................40Figura 7: Esquema WSDL...............................................................................................49Figura 8: Elementos arquitectura.....................................................................................54Figura 9: Cliente-Servidor...............................................................................................56Figura 10: Stateless..........................................................................................................56Figura 11: Caché..............................................................................................................57Figura 12: Sistema de capas............................................................................................58Figura 13: Funcionamiento REST...................................................................................61Figura 14: Representación de recurso.............................................................................63Figura 15: Mecanismo caché...........................................................................................66Figura 16: Vista proceso..................................................................................................69Figura 17: Vista conector................................................................................................70Figura 18: Tiempo de retardo..........................................................................................72Figura 19: REST transición de estados...........................................................................74Figura 20: Solicitud recurso............................................................................................76Figura 21: Representación recurso dinámico..................................................................76Figura 22: Modificación Recurso....................................................................................77Figura 23: Versiones HTTP Cliente-Servidor.................................................................80Figura 24: Mensaje HTTP, URL HOST..........................................................................83Figura 25: Negociación del contenido.............................................................................85Figura 26: Comportamiento Firewall..............................................................................88Figura 27: % Importancia de REST en la Web.............................................................139Figura 28: Temporización del proyecto........................................................................142

INDICE DE TABLAS

Tabla 1 Lista de códigos de estado http...........................................................................29Tabla 2 Mapeo entre tipos SOAP y JAVA......................................................................44Tabla 3 Tipos de diseño de datos....................................................................................60Tabla 4 Elementos de Datos REST.................................................................................64Tabla 5 Conectores REST...............................................................................................67Tabla 6 Componentes REST...........................................................................................68Tabla 7 Significado mensajes HTTP...............................................................................81Tabla 8 Métodos REST...................................................................................................87Tabla 9 Costes de personal............................................................................................143Tabla 10 Costes de Software.........................................................................................143Tabla 11 Costes de Hardware........................................................................................144Tabla 12 Otros Costes...................................................................................................144Tabla 13 Total Costes....................................................................................................144

GLOSARIO

APACHE: Servidor HTTP de código abierto

API: Aplication Programming Interface

ASP: Active Server Pages

B2B: Business to Business, comercio electrónico entre empresas

COM: Component Object Model

CORBA: Common Object Request Broker Architecture

CSS: Cascading Style Sheets

DCE: Distributed Computing Environment

DCOM: Distributed Component Objet Model

DOM: Document Objet Model

DTD: Document Type Definition

EJB: Enterprise JavaBeans

FreeBSD: Sistema operativo libre

FTP: File Transfer Protocol

GOPHER: Servicio Web basado en acceso a menús

GUID: Globally Unique Identifier

HTML: HyperText Markup Language

HTTP: Hypertext transfer Protocol

HTTPS: Secure HTTP

IP: Internet Protocol

ISO: International Organization for Standarization

JSP: JavaServer Pages

LDAP: Lightweight Directory Access Protocol

MIME: Multi-Purpose Internet Mail Extension

OASIS: Organization for the Advancement of Structured Information Standards

OSF: Open Software Foundation

P2P: Peer to Peer

REST: Representational State Transfer

RESTAFARIAN: Defensor o adepto a REST

RESTLET: API que aplica los principios de REST a Servlets

RFC: Request for Comment, conjunto de documentos que recogen estándares o normas

RPC: Remote Procedure Call

SCRIPT: Programa escrito para un lenguaje interpretado o Shell

SGML: Standard Generalized Markup Language

SOAP: Simple Object Access Protocol

SSL: Secure Socket Layers

TCP: Transmision Control Protocol

TELNET: Protocolo para acceso remoto a máquinas

TSL: Transport Secure Layer

UDDI: Universal Description, Discovery and Integration

UDP: User Datagram Protocol

URI: Uniform resource Identifier

URL: Uniform Resource Locator

URN: Uniform Resource Names

UUID: Universally Unique Identifier

W3C: World Wide Web Consortium

WAIS: Wide Area Information Server

WSDL: Web Services Description Language

XML: Extensible Markup Language

XSD: XML Schema Definition

1 OBJETIVOS

Este proyecto presenta Representational State Transfer (REST), un estilo de arquitectura para Servicios Web. La motivación de desarrollar REST es crear un modelo de arquitectura que describa como debería funcionar la Web, así como que sirva de marco de trabajo para los estándares de protocolos. REST ha sido aplicado para describir la arquitectura Web deseada, ayudar a identificar problemas existentes y comparar soluciones alternativas, asegurando siempre que los protocolos no violen las restricciones que hacen que la Web funcione correctamente.

Este estilo de arquitectura salió a la luz de la mano de Roy Thomas Fielding en el año 2000, concibiéndola de una manera abierta (abstracta), pero posteriormente, se le ha ido dando forma para que encaje perfectamente en el mundo Web, usando las tecnologías existentes, tales como:

URI, como identificador de recursos. HTTP, como protocolo de transferencia. XML, como sintaxis de descripción y estructurado de datos

El objetivo principal de este proyecto es realizar una panorámica y estado del arte de los Servicios Web centrada en REST. Para ello se va a dividir el proyecto en varias tareas u objetivos secundarios:

Introducir el mundo de los Servicios Web exponiendo los conceptos de localizador de recursos URI, protocolo de transferencia HTTP y lenguaje de marcas XML. Estas son las bases sobre las que se construyen los estilos de arquitectura Web REST y SOAP. Su estudio es imprescindible para poder comprenderlos.

Exponer las bases y el funcionamiento del estilo de arquitectura REST de acuerdo con la información disponible.

Analizar la situación actual de REST, estudiando algunas de las implementaciones que existen.

Realizar una comparación entre REST y la tecnología de Servicios Web SOAP, distinguiendo las ventajas e inconvenientes de cada uno.

Hacer una predicción del futuro que cabe esperar a REST, teniendo en cuenta que actualmente SOAP está mucho más extendido entre los desarrolladores de Servicios Web.

.

REST rápidamente fue calificado como una alternativa a SOAP y da una nueva visión general de los Servicios Web en entornos distribuidos.

2 INTRODUCCIÓN

Las telecomunicaciones constituyen un elemento clave de la Sociedad de la Información, facilitando el acceso e intercambio de datos entre personas o máquinas, sistemas e instituciones. No es posible entender el actual progreso socioeconómico, sin tener presente el despliegue de redes de comunicaciones cada vez más sofisticadas (fijas, de cable, satélite, móviles, etc.)

El hombre moderno cada vez quiere realizar una mayor cantidad de tareas con menos esfuerzo. De todas las tecnologías que actualmente ayudan a hacer esto posible, Internet es una de las más importantes. Gracias al rápido avance que está teniendo, una persona puede realizar tareas muy diversas con un coste de tiempo que sería impensable hace algunas décadas. Desde casa se tiene acceso a prácticamente toda la información existente en el mundo, se puede realizar una compra, visitar un museo, etc.

Como puede verse, las tareas se simplifican porque se trasladan desde su origen físico hasta la casa del usuario, a través de Internet. Los responsables de que esto sea posible son los Servicios Web.

Existen múltiples definiciones sobre lo que son los Servicios Web, lo que muestra su complejidad a la hora de dar una adecuada definición que englobe todo lo que son e implican:

El W3C nos da la siguiente definición de Servicios Web [1]:

Son un conjunto de aplicaciones o de tecnologías con capacidad para interoperar en la Web. Estas aplicaciones o tecnologías intercambian datos entre sí con el objetivo de ofrecer unos servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan un servicio llamando a estos procedimientos a través de la Web.

Estos servicios proporcionan mecanismos de comunicación estándares entre diferentes aplicaciones, que interactúan entre sí para presentar información dinámica al usuario. Para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones, y que al mismo tiempo sea posible su combinación para realizar operaciones complejas, es necesaria una arquitectura de referencia estándar.

Otra posible definición la encontramos en Wikipedia [2]:

Un servicio Web es una colección de protocolos y estándares que sirve para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferentes y ejecutadas sobre cualquier plataforma pueden utilizar los servicios Web para intercambiar datos en redes de ordenadores como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos. Las organizaciones OASIS y W3C son los comités responsables de la arquitectura y reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I, encargado de desarrollar diversos perfiles para definir de manera más exhaustiva estos estándares.

Teniendo en cuenta estas definiciones, se puede decir de forma muy sencilla y resumida, que los servicios Web son los que hacen posible que una persona que necesita un servicio y otra que lo ofrezca, puedan ponerse de acuerdo y llevar a cabo la operación a través de Internet.

Figura 1: Servicios Web

El mundo de los Servicios Web data de las últimas dos décadas y poco a poco se está descubriendo su potencial. Pero para poder explotarlo totalmente, todavía queda mucho trabajo por hacer. La investigación de esta disciplina no está relegada al ámbito académico. Las empresas están viendo que el mundo de los Servicios Web puede ofrecer grandes beneficios al que sepa aprovecharlo. Estas investigaciones complementarias que existen, son la clave para que los Servicios Web estén avanzando tan rápidamente

Actualmente el mundo de los Servicios Web es prácticamente un monopolio de la arquitectura de Servicios Web SOAP, la mayor parte de los Servicios Web que se diseñan usan un marco de trabajo SOAP.

Este proyecto va a presentar REST, que es un estilo de arquitectura para Servicios Web que surgió en 2002 de la mano de Roy Thomas Fielding. Cuando Roy Fielding sacó a la luz su disertación, toda la red se hizo eco de ello. Surgieron muchos artículos que cuestionaban la eficiencia de SOAP. En algunos sectores se creyó que REST podía ser la solución al monopolio que tenía SOAP.

A continuación se expondrán los capítulos que van a dar forma a este estudio de REST, indicando la finalidad de cada uno.

2.1 Temática de los capítulos

En los capítulos posteriores se estudiarán más detenidamente los Servicios Web, especialmente el estilo de arquitectura REST, que es el punto sobre el que se centra el proyecto.

La temática de los siguientes capítulos es:

Capítulo 3, Conceptos previos: En este capítulo se verán los conceptos de localizador de recursos (URL y UUID), protocolo de transferencia (HTTP) y lenguaje de marcas para describir y estructurar los datos (XML). Estas son las bases sobre las que se construyen los estilos de arquitectura Web REST y SOAP. Su estudio es imprescindible para poder comprenderlos.

Capítulo 4, SOAP y WSDL: En este capítulo se verá la arquitectura de Servicios Web SOAP y el lenguaje de descripción de Servicios WSDL. Este capítulo es necesario para poder realizar comparaciones entre REST y SOAP, porque REST surge como alternativa al monopolio que posee SOAP en el mundo de los Servicios Web.

Capítulo 5, Representational State Transfer:REST, En este capítulo queda recogida una visión actual del estilo de arquitectura REST. La base del capítulo es la disertación de Roy Thomas Fielding, aunque también añade algunos detalles del funcionamiento que surgieron posteriormente.

Capítulo 6, Debate REST-SOAP: En este capítulo se pretende dar una visión general del debate que ha existido en la Web entorno a la comparación entre REST y SOAP. Se exponen los artículos más relevantes que se han escrito hasta el momento.

Capítulo 7, Implementaciones: En este capítulo se comentan algunos de los Servicios Web que están actualmente funcionando de acuerdo al modelo de arquitectura REST. Además se proporciona un ejemplo para comprender mejor el diseño de un Servicio Web y se incluye un artículo que enumera los principales errores de implementación.

Capítulo 8, Evolución y Futuro de REST: En este capítulo se hace un seguimiento de la relevancia que ha tenido REST en la Web desde que salió a la luz. Además se intenta dar una previsión del futuro que le espera a REST.

3 CONCEPTOS PREVIOS

Para poder ahondar más en el mundo de los Servicios Web, y más particularmente en REST, es necesario introducir algunos conceptos previos. En este capítulo se verán los conceptos de localizador de recursos (URL y UUID), protocolo de transferencia (HTTP) y lenguaje de marcas para describir y estructurar los datos (XML). Estas son las bases sobre las que se construyen los estilos de arquitectura Web REST y SOAP. Su estudio es imprescindible para poder comprenderlos.

3.1 URL

URL significa Uniform Resource Locutor [4], es decir, localizador uniforme de recurso. Es una secuencia de caracteres, de acuerdo a un formato estándar, que se usa para nombrar recursos, como documentos e imágenes en Internet, por su localización.

Las URL [RFC 1738] fueron una innovación fundamental en la historia de Internet. Fueron usadas por primera vez por Tim Berners-Lee en 1991, para permitir a los autores de documentos establecer hiperenlaces en la World Wide Web (WWW o Web). Desde 1994, en los estándares Internet, el concepto de URL ha sido incorporado dentro del más general de URI (Uniform Resource Identifier - Identificador Uniforme de Recurso), pero el término URL aún se utiliza ampliamente.

Aunque nunca fueron mencionadas como tal en ningún estándar, mucha gente cree que las iniciales URL significan Universal Resource Locator (Localizador Universal de Recurso). Esta interpretación puede ser debida al hecho de que, aunque la U en URL siempre ha significado Uniforme, la U de URI significó en un principio Universal, antes de la publicación del [RFC 2396].

La URL es la cadena de caracteres con la cual se asigna una dirección única a cada uno de los recursos de información disponibles en Internet. Existe un URL único para cada página de cada uno de los documentos de la World Wide Web, para todos los elementos de Gopher y todos los grupos de debate USENET, y así sucesivamente.

El URL de un recurso de información es su dirección en Internet, la cual permite que el navegador la encuentre y la muestre de forma adecuada. Por ello el URL combina el nombre del ordenador que proporciona la información, el directorio donde se encuentra, el nombre del fichero y el protocolo a usar para recuperar los datos. Y reemplaza la dirección numérica o IP de los servidores haciendo de esta manera más fácil la navegación, si no de otra forma se tendría que hacer bajo direcciones del tipo http://148.210.01.7 en vez de http://pagina.com

3.1.1 Sintaxis

El formato general de una URL es:

protocolo://máquina/directorio/fichero

También pueden añadirse otros datos:

protocolo://usuario:contraseña@máquina:puerto/directorio/fichero

Por ejemplo: http://es.Wikipedia.org/

La especificación detallada se encuentra en la [RFC 1738], titulada Uniform Resource Locators.

3.1.1.1 Esquema URL

Una URL se clasifica por su esquema, que generalmente indica el protocolo de red que se usa para recuperar, a través de la red, la información del recurso identificado. Una URL comienza con el nombre de su esquema, seguida por dos puntos, seguido por una parte específica del esquema.

Algunos ejemplos de esquemas URL: http – recursos HTTP https - HTTP sobre SSL ftp – File Transfer Protocol mailto - direcciones E-mail ldap - búsquedas LDAP Lightweight Directory Access Protocol file - recusos disponibles en el ordenador local, o en una red local news - grupos de noticias Usenet (newsgroup) gopher - el protocolo Ghoper(ya en desuso) telnet - el protocolo telnet data - el esquema para insertar pequeños trozos de contenido en los documentos

Data: URL

Algunos de los esquemas URL, como los populares "mailto", "http", "ftp" y "file", junto a los de sintaxis general URL, se detallaron por primera vez en 1994, en el Request for Comments [RFC 1630].

3.1.1.2 Sintaxis Genérica URL

Todas las URLs, independientemente del esquema, deben seguir una sintaxis general. Cada esquema puede determinar sus propios requisitos de sintaxis para su parte específica, pero la URL completa debe seguir la sintaxis general.

Usando un conjunto limitado de caracteres, compatible con el subconjunto imprimible de ASCII, la sintaxis genérica permite a las URLs representar la dirección de un recurso, independientemente de la forma original de los componentes de la dirección.

Los esquemas que usan protocolos típicos basados en conexión usan una sintaxis común para "URI genéricas", definida a continuación:

esquema://autoridad/ruta?consulta#fragmento

La autoridad consiste usualmente en el nombre o Dirección IP de un servidor, seguido a veces de dos puntos (":") y un número de puerto TCP. También puede incluir un nombre de usuario y una clave, para autenticarse ante el servidor.

La ruta es la especificación de una ubicación en alguna estructura jerárquica, usando una barra diagonal ("/") como delimitador entre componentes.

La consulta habitualmente indica parámetros de una consulta dinámica a alguna base de datos o proceso residente en el servidor.

El fragmento identifica a una porción de un recurso, habitualmente una ubicación en un documento.

3.1.1.2.1 Ejemplo: URLs en HTTP

Las URLs empleadas por HTTP, el protocolo usado para transmitir páginas Web, es el tipo más popular de URL y puede ser usado para mostrarse como ejemplo. La sintaxis de una HTTP URL es:

esquema://anfitrión:puerto/ruta?parámetro=valor#enlace Esquema, en el caso de HTTP, en la mayoría de las veces equivale a http, pero

también puede ser https cuando se trata de HTTP sobre una conexión TLS (para hacer más segura la conexión).

Muchos navegadores Web permiten el uso de la siguiente estructura: esquema://usuario:contraseña@anfitrión:puerto/... para autenticación en HTTP. Este formato ha sido usado como una "hazaña" para hacer difícil el identificar correctamente al servidor involucrado. En consecuencia, el soporte para este formato ha sido dejado de lado por algunos navegadores. La sección 3.2.1 de RFC 3986 recomienda que los navegadores deben mostrar el usuario / contraseña de otra forma que no sea en la barra de direcciones, a causa de los problemas de seguridad mencionados y porque las contraseñas no deben ser nunca mostradas como texto claro.

Anfitrión, la cual es probablemente la parte que más sobresale de una URL, es en casi todos los casos el nombre de dominio de un servidor, p.ej.: www.wikipedia.org, google.com, etc.

La porción :puerto especifica un número de puerto TCP. Normalmente es omitido (en este caso, su valor por omisión es 80) y probablemente, para el usuario es lo que tiene menor relevancia en todo el URL.

La porción ruta es usada por el servidor (especificado en anfitrión) de cualquier forma en la que su software lo establezca, pero en muchos casos se usa para especificar un nombre de archivo, posiblemente precedido por nombres de directorio. Por ejemplo, en la ruta /wiki/Vaca, wiki sería un (seudo-)directorio y Vaca sería un (seudo-)nombre de archivo.

La parte mostrada arriba como ?parámetro=valor se conoce como porción de consulta (o también, porción de búsqueda). Puede ser omitido, puede haber una sola pareja parámetro-valor como en el ejemplo, o pueden haber muchas de ellas, lo cual se expresa como ?param=valor&otroParam=valor&.... Las parejas parámetro-valor sólo son relevantes si el archivo especificado por la ruta no es una página Web simple y estática, sino algún tipo de página automáticamente generada. El software generador usa las parejas parámetro-valor de cualquier forma en que se establezca; en su mayoría transportan información específica a un usuario y un momento en el uso del sitio, como términos concretos de búsqueda, nombres de usuario, etc. (Observe, por ejemplo, de qué forma se comporta URL en la barra de direcciones de su navegador durante una búsqueda Google: su término de búsqueda es pasado a algún programa sofisticado en google.com como un parámetro, y el programa de Google devuelve una página con los resultados de la búsqueda.)

La parte #enlace, por último, es conocida como identificador de fragmento y se refiere a ciertos lugares significativos dentro de una página; por ejemplo, esta página tiene enlaces internos hacia cada cabecera de sección a la cual se puede dirigir usando el ID de fragmento. Esto es relevante cuando una URL de una página ya cargada en un navegador permite saltar a cierto punto en una página larga. Un ejemplo sería un enlace que conduce a la misma página y al comienzo de la sección. (Observe que cambiará la URL en la barra de dirección del navegador).

3.1.2 URI y Referencias URI

URI es un Uniform Resource Identifier, identificador uniforme de recursos [3]. Texto corto que identifica unívocamente cualquier recurso (servicio, página, documento, dirección de correo electrónico, enciclopedia...) accesible en una red.

Normalmente un URI consta de dos partes: Identificador del método de acceso (protocolo) al recurso, por ejemplo http:,

mailto:, ftp: Nombre del recurso, por ejemplo "//es.Wikipedia.org"

La especificación detallada se encuentra en la [RFC 2396] - Uniform Resource Identifiers (URI): Generic Syntax.

La principal diferencia entre la definición de URI y URL es que las URIs identifican a cualquier recurso pero no tienen por qué indicar como acceder al mismo. Las URL

indican como acceder al recurso. Como puede verse, la definición de URI es más genérica, engloba a URL dentro de ella.

Figura 2: URI-URL

El término referencia URI se refiere a un caso particular de una URI, o una porción de éste, tal como es usada en un documento HTML, por ejemplo, para referirse a un recurso particular. Una referencia URI habitualmente se parece a una URL o a la parte final de una URL. Las referencias URI introducen dos nuevos conceptos: la distinción entre referencias absolutas y relativas, y el concepto de un identificador de fragmento.

Un URL absoluto es una referencia URI que es parecida a las URLs definidas arriba; empieza por un esquema seguido de dos puntos (":") y de una parte específica del esquema. Una URL relativa es una referencia URI que comprende sólo la parte específica del esquema de una URL, o de algún componente de seguimiento de aquella parte. El esquema y componentes principales se infieren del contexto en el cual aparece la referencia URL: el URI base (o URL base) del documento que contiene la referencia.

Una referencia URI también puede estar seguida de un carácter de numeral ("#") y un puntero dentro del recurso referenciado por el URI en conjunto. Esto no es parte de la URI como tal, sino que es pensado para que el "agente usuario" (el navegador) lo interprete después que una representación del recurso ha sido recuperada. Por tanto, no se supone que sean enviadas al servidor en forma de solicitudes HTTP.

Ejemplos de URLs absolutos: http://es.wikipedia.org/w/wiki.phtml?title=URL&action=history http://es.wikipedia.org/wiki/URL#Esquemas_en_URL

Ejemplos de URLs relativos:

//en.wikipedia.org/wiki/Uniform_Resource_Locator /wiki/URL URL#Referencias_URI

3.1.3 Diferenciación entre mayúsculas/minúsculas

De acuerdo al estándar actual, en los componentes esquema y anfitrión no se diferencian mayúsculas y minúsculas, y cuando se normalizan durante el procesamiento, deben estar en minúsculas. Se debe asumir que en otros componentes sí hay diferenciación. Sin embargo, en la práctica, en otros componentes aparte de los de protocolo y anfitrión, esta diferenciación es dependiente del servidor Web y del sistema operativo del sistema que albergue al servidor.

3.1.4 URLs en el uso diario

Un HTTP URL combina en una dirección simple los cuatro elementos básicos de información que son necesarios para recuperar un recurso desde cualquier parte de Internet:

El protocolo que se usa para comunicar, El anfitrión (servidor) con el que se comunica, El puerto de red en el servidor para conectarse, La ruta al recurso en el servidor (por ejemplo, su nombre de archivo).

Un URL típico puede lucir como:

http://es.wikipedia.org:80/wiki/Special:Search?search=tren&go=Go

Donde: http es el protocolo, es.wikipedia.org es el anfitrión, 80 es el número de puerto de red en el servidor (siendo 80 el valor por omisión

para el protocolo HTTP, esta porción puede ser omitida por completo), /wiki/Special:Search es la ruta de recurso, ?search=tren&go=Go es la cadena de búsqueda; esta parte es opcional.

Muchos navegadores Web no requieren que el usuario ingrese "http://" para dirigirse a una página Web, puesto que HTTP es el protocolo más común que se usa en navegadores Web. Igualmente, dado que 80 es el puerto por omisión para HTTP, usualmente no se especifica. Usualmente uno sólo ingresa una URL parcial tal como www.wikipedia.org/wiki/Train. Para ir a una página principal normalmente se entra sólo el nombre de anfitrión, como www.wikipedia.org.

Dado que el protocolo HTTP permite que un servidor responda a una solicitud redireccionando el navegador Web a una URL diferente, muchos servidores adicionalmente permiten a los usuarios omitir ciertas partes de la URL, tales como la

parte "www.", o el carácter numeral ("#") de rastreo si el recurso en cuestión es un directorio. Sin embargo, estas omisiones técnicamente constituyen una URL diferente, de modo que el navegador Web no puede hacer estos ajustes, y tiene que confiar que el servidor responda con una redirección. Es posible para un servidor Web (pero debido a una extraña tradición) ofrecer dos páginas diferentes para URLs que difieren únicamente en un carácter "#".

Nótese que en es.wikipedia.org/wiki/Tren, el orden jerárquico de los cinco elementos es org (dominio genérico de nivel superior) - wikipedia (dominio de segundo nivel) - es (subdominio) - wiki - Train; es decir, antes del primer "/" se lee de derecha a izquierda, y después el resto se lee de izquierda a derecha.

3.1.5 El gran marco

El término URL también es usado fuera del contexto de la World Wide Web. Los servidores de bases de datos especifican URLs como un parámetro para hacer conexiones a éstos. De forma similar, cualquier aplicación cliente-servidor que siga un protocolo particular puede especificar un formato URL como parte de su proceso de comunicación.

Ejemplo de una URL en una base de datos:

jdbc:datadirect:oracle://myserver:1521;sid=testdb

Si una página Web está en forma singular y más o menos permanentemente definida a través de una URL, ésta puede ser enlazada. Éste no siempre es el caso, por ejemplo., una opción de menú puede cambiar el contenido de un marco dentro de la página, sin que esta nueva combinación tenga su propia URL. Una página Web puede depender también de información almacenada temporalmente. Si el marco o página Web tiene su propia URL, esto no es siempre obvio para alguien que quiere enlazarse a ella: la URL de un marco no es mostrado en la barra de direcciones del navegador, y una página sin barra de dirección pudo haber sido producida. La URL se puede encontrar en el código fuente y/o en las "propiedades" de varios componentes de la página.Aparte del propósito de enlazarse a una página o a un componente de página, puede ocurrir que se quiera conocer el URL para mostrar únicamente el componente, o superar restricciones tales como una ventana de navegador que no tenga barras de herramientas y/o que sea de tamaño pequeño y no ajustable.

Los servidores Web también tienen la capacidad de direccionar URLs si el destino ha cambiado, permitiendo a los sitios cambiar su estructura sin afectar los enlaces existentes. Este proceso se conoce como redireccionamiento de URLs.

3.2 UUID

Un Universally Unique Identifier [RFC 4122] es un identificador estándar usado en la construcción de Software, estandarizado por el Open Software Foundation (OSF) como

parte del Distributed Computing Environment (DCE) [27]. La función de los UUIDs es permitir a los sistemas distribuidos identificar información única sin necesidad de un sistema de coordinación central. Así, cualquiera puede crear UUID y usarla para identificar algo con cierta confianza de que el identificador nunca se usará inintencionadamente por otra persona. La información etiquetada con UUIDs puede ser usada en bases de datos simples sin necesidad de resolver conflictos de nombres. El uso más extendido de este estándar son las Microsoft´s Globally Unique Identifiers (GUIDs) que implementan este estándar.

Un UUID es esencialmente un número de 16 octetos y su forma canónica se parece a algo como esto:

550e8400-e29b-11d4-a716-446655440000

Los UUIDs se documentan como parte de ISO/IEC 11578:1996 “Information technology -- Open System Interconection – Remote Procedura Call (RPC)”.

El esquema de UUIDs fue criticado por no ser suficientemente opaco; revelaba la identidad del ordenador que generaba el UUID y el momento en el que lo hizo.

3.3 HTTP

El Protocolo de Transferencia de Hipertexto (Hypertext Transfer Protocol) es un sencillo protocolo cliente-servidor que articula los intercambios de información entre los clientes Web y los servidores HTTP. La especificación completa del protocolo HTTP 1/0 está recogida en el [RFC 1945]. Fue propuesto por Tim Berners-Lee, atendiendo a las necesidades de un sistema global de distribución de información como el World Wide Web.

3.3.1 Características y funcionamiento

Desde el punto de vista de las comunicaciones, está soportado sobre los servicios de conexión TCP/IP, y funciona de la misma forma que el resto de los servicios comunes de entornos UNIX: un proceso servidor escucha en un puerto de comunicaciones TCP (por defecto, el 80), y espera las solicitudes de conexión de los clientes Web. Una vez que se establece la conexión, el protocolo TCP se encarga de mantener la comunicación y garantizar un intercambio de datos libre de errores.

HTTP se basa en sencillas operaciones de solicitud/respuesta. Un cliente establece una conexión con un servidor y envía un mensaje con los datos de la solicitud. El servidor responde con un mensaje similar, que contiene el estado de la operación y su posible resultado. Todas las operaciones pueden adjuntar un objeto o recurso sobre el que actúan; cada objeto Web es conocido por su URL.

Los recursos u objetos que actúan como entrada o salida de un comando HTTP están clasificados por su descripción MIME. De esta forma, el protocolo puede intercambiar cualquier tipo de dato, sin preocuparse de su contenido. La transferencia se realiza en modo binario, byte a byte, y la identificación MIME permitirá que el receptor trate adecuadamente los datos.

Las principales características del protocolo HTTP son:

Toda la comunicación entre los clientes y servidores se realiza a partir de caracteres de 8 bits. De esta forma, se puede transmitir cualquier tipo de documento: texto, binario, etc., respetando su formato original.

Permite la transferencia de objetos multimedia. El contenido de cada objeto intercambiado está identificado por su clasificación MIME.

Existen tres verbos básicos (hay más, pero por lo general no se utilizan) que un cliente puede utilizar para dialogar con el servidor: GET, para recoger un objeto, POST, para enviar información al servidor y HEAD, para solicitar las características de un objeto (por ejemplo, la fecha de modificación de un documento HTML).

Cada operación HTTP implica una conexión con el servidor, que es liberada al término de la misma. Es decir, en una operación se puede recoger un único objeto. En la actualidad se ha mejorado este procedimiento, permitiendo que una misma conexión se mantenga activa durante un cierto periodo de tiempo, de forma que sea utilizada en sucesivas transacciones. Este mecanismo, denominado HTTP Keep Alive, es empleado por la mayoría de los clientes y servidores modernos.

No mantiene estado. Cada petición de un cliente a un servidor no es influida por las transacciones anteriores. El servidor trata cada petición como una operación totalmente independiente del resto.

Cada objeto al que se aplican los verbos del protocolo está identificado a través de la información de situación del final de la URL.

Cada vez que un cliente realiza una petición a un servidor, se ejecutan los siguientes pasos:

1. Un usuario accede a una URL, seleccionando un enlace de un documento HTML o introduciéndola directamente en el campo Dirección del cliente Web.

2. El cliente Web descodifica la URL, separando sus diferentes partes. Así identifica el protocolo de acceso, la dirección DNS o IP del servidor, el posible puerto opcional (el valor por defecto es 80) y el objeto requerido del servidor.

3. Se abre una conexión TCP/IP con el servidor, llamando al puerto TCP correspondiente.

4. Se realiza la petición. Para ello, se envía el comando necesario (GET, POST, HEAD,…), la dirección del objeto requerido (el contenido de la URL que sigue a la dirección del servidor), la versión del protocolo HTTP empleada (casi siempre HTTP/1.0) y un conjunto variable de información, que incluye datos sobre las capacidades del navegador, datos opcionales para el servidor, etc.

5. El servidor devuelve la respuesta al cliente. Consiste en un código de estado y el tipo de dato MIME de la información de retorno, seguido de la propia información.

6. Se cierra la conexión TCP. Si no se utiliza el modo HTTP Keep Alive, este proceso se repite para cada acceso al servidor HTTP.

A continuación se muestra un esquema gráfico de este proceso en la Figura [3]:

Figura 3: Petición HTTP

El diálogo con los servidores HTTP se establece a través de mensajes formados por líneas de texto, cada una de las cuales contiene los diferentes comandos y opciones del protocolo. Sólo existen dos tipos de mensajes, uno para realizar peticiones y otro para devolver la correspondiente respuesta. La estructura general de los dos tipos de mensajes se puede ver en el siguiente esquema de la Figura [4]:

Figura 4: Mensaje HTTP para solicitud/respuesta

La primera línea del mensaje de solicitud contiene el comando que se solicita al servidor HTTP, mientras que en la respuesta contiene el resultado de la operación que es un código numérico que permite conocer el éxito o fracaso de la operación. Después aparece, para ambos tipos de mensajes, un conjunto de cabeceras (obligatorias y opcionales), que condicionan y matizan el funcionamiento del protocolo.

La separación entre cada línea del mensaje se realiza con un par CR-LF (retorno de carro más nueva línea). El final de las cabeceras se indica con una línea en blanco, tras la cual se pueden incluir los datos transportados por el protocolo, por ejemplo, el documento HTML que devuelve un servidor.

3.3.2 Comandos del protocolo HTTP

El protocolo HTTP consta de los siguientes comandos que permiten realizar las acciones pertinentes: GET, HEAD, POST, PUT, DELETE, LINK, UNLINK. A continuación se va a explicar detenidamente cada uno de ellos:

GET, se usa para recoger cualquier tipo de información del servidor. Se utiliza siempre que se pulsa sobre un enlace o se teclea directamente a una URL. Como resultado, el servidor HTTP envía el documento correspondiente a la URL.

Este comando puede ir acompañado de una cabecera con los siguientes parámetros:

Accept: indica los formatos de archivo que puede soportar el cliente.

Accept-Charset: indica los conjuntos de caracteres que acepta.

Accept-Encoding: el tipo de codificación que acepta.

Accept-Language: el lenguaje en el que se hará la respuesta de la cabecera.

Authorization: clave para tener acceso a lugares restringidos donde se requiere nombre de contraseña y el formato de autorización empleado.

Connection: especifica las opciones requeridas para una conexión.

Date: representa la fecha y la hora a la que se envió el comando.

From: campo opcional que incluye la dirección de correo electrónico del usuario del cliente.

Host: especifica la dirección del host del cliente y el puerto de conexión que ha empleado.

If-Modified-Since: condición de que sólo se responda a la solicitud si la fecha de última modificación del objeto es superior a la indicada en su parámetro.

If-UnModified-Since: sólo se responde a la solicitud si la fecha de última modificación del objeto no ha cambiado a partir de la fecha indicada en su parámetro.

Pragma: para incluir directivas de implementación.

Proxy-Authorization: para identificarse a un Proxy.

Referer: contiene la URL de la página que le ha dado acceso a la que está solicitando. Esto puede interesarle a los autores de páginas Web para saber en que lugares existen enlaces de su página.

Range: establecer un rango de Bytes del contenido de la respuesta.

Transfer-Encoding: indica el tipo de codificación aplicada del contenido que responderá el servidor.

Upgrade: especifica qué protocolos suplementarios soporta el cliente, si también soportara FTP u otros.

User-Agent: especifica cual es el nombre del cliente y su versión. Tiene un segundo parámetro corresponde al sistema operativo donde corre el cliente.

Via: sirve para obtener la ruta de routers que ha recorrido el mensaje.

HEAD, que es igual que el comando GET, y puede usar las mismas cabeceras, pero este comando le pide al servidor que le envíe sólo la cabecera como respuesta. Es utilizado por los gestores de caché de páginas o los servidores proxy, para conocer cuándo es necesario actualizar la copia que se mantiene de un fichero.

POST, que tiene un funcionamiento idéntico al comando HEAD, pero además, este comando envía datos de información al servidor, normalmente originaria de un formulario Web para que el servidor los administre o los añada a una base de datos.

Posteriormente se han definido algunos comandos adicionales, que sólo están disponibles en determinadas versiones de servidores HTTP. La última versión de HTTP, denominada 1.1, recoge estas y otras novedades, que se pueden utilizar, por ejemplo:

PUT, actualiza información sobre un objeto del servidor. Es similar a POST, pero en este caso, la información enviada al servidor debe ser almacenada en la URL que acompaña al comando. Así se puede actualizar el contenido de un documento.

DELETE, elimina el documento especificado del servidor.

LINK, crea una relación entre documentos.

UNLINK, elimina una relación existente entre documentos del servidor.

Estos métodos pueden usarse, por ejemplo, para editar las páginas de un servidor Web trabajando de manera remota.

Cuando el servidor envía la respuesta al cliente, le envía la información solicitada y una cabecera con una serie campos, estos campos son:

Age: tiempo transcurrido desde que se creó la respuesta.

Allow: especifica qué comandos puede utilizar el cliente respecto al objeto pedido, como pueden ser GET o HEAD.

Expires: fecha en la que caducará el objeto adjunto.

Last-Modified: fecha de la última modificación del objeto.

Location: se usa para redirigir la petición a otro objeto. Informa sobre la dirección exacta del objeto al que se ha accedido.

Proxy-Authenticate: indica el esquema de autentificación en caso de que un Proxy lo requiera.

Public: da una lista de los comandos que reconoce el servidor.

Retry-After: si no puede ofrecer un objeto provisionalmente, indica la fecha para que se vuelva a hacer la petición.

Server: especifica el tipo y versión del servidor.

Vary: indica que hay mas de una posible respuesta a la petición pero solo elige una.

Warning: específica información adicional sobre el estado de la respuesta.

WWW-Autenticate: usado cuando se accede a un lugar restringido, sirve para informar de las maneras de autentificarse que soporta el objeto del servidor.

Hay otros parámetros de información de cabeceras, que son válidos tanto para mensajes del cliente como para respuestas del servidor. Estas cabeceras son:

Content-Type: descripción MIME de la información que contiene el mensaje para dar el tratamiento conveniente a los datos que se envían.

Content-Length: longitud en Bytes de los datos enviados.

Content-Encoding: especifica el formato en el que están codificados los datos enviados.

Date: fecha local de la operación. Las fechas deben incluir la zona horaria en que reside el sistema que genera la operación. Por ejemplo: Sunday, 12- Dec-96 12:21:22 GMT+01. No existe un formato único en las fechas; incluso es posible encontrar casos en los que no se dispone de la zona horaria correspondiente, con los problemas de sincronización que esto produce. Los formatos de fecha a emplear están recogidos en las [RFC 1036] y [RFC 1123].

Pragma: Permite incluir información variada relacionada con el protocolo HTTP en la solicitud o respuesta que se está realizando. Por ejemplo, un cliente envía un Pragma: no-caché para informar de que desea una copia nueva del recurso especificado.

Ante cada transacción con un servidor HTTP, éste devuelve un código numérico que informa sobre el resultado de la operación, como primera línea del mensaje de respuesta. Estos códigos aparecen en algunos casos en la pantalla del cliente, cuando se produce un error.

Los códigos de estados están clasificados en cinco categorías:

1xx: mensajes informativos. En HTTP/1.0 no se utilizan, y están reservados para un futuro uso.

2xx: mensajes asociados con operaciones realizadas correctamente.

3xx: mensajes de redirección, que informan de operaciones complementarias que se deben realizar para finalizar la operación.

4xx: errores del cliente; el requerimiento contiene algún error, o no puede ser realizado.

5xx: errores del servidor, que no ha podido llevar a cabo una solicitud.

La lista de códigos es la que podemos ver en la Tabla [1]

Código Comentario Descripción

200 OK Operación realizada satisfactoriamente.

201 Created

La operación ha sido realizada correctamente, y como resultado se ha creado un nuevo objeto, cuya URL de acceso se proporciona en el cuerpo de la respuesta. Este nuevo objeto ya está disponible. Puede ser utilizado en sistemas de edición de documentos.

202 Accepted

La operación ha sido realizada correctamente, y como resultado se ha creado un nuevo objeto, cuya URL de acceso se proporciona en el cuerpo de la respuesta. El nuevo objeto no está disponible por el momento. En el cuerpo de la respuesta se debe informar sobre la disponibilidad de la información.

204 No ContentLa operación ha sido aceptada, pero no ha producido ningún resultado de interés. El cliente no deberá modificar el documento que está mostrando en este momento.

301 Moved Permanently

El objeto al que se accede ha sido movido a otro lugar de forma permanente. El servidor proporciona, además, la nueva URL en la variable Location de la respuesta. Algunos browsers acceden automáticamente a la nueva URL. En caso de tener capacidad, el cliente puede actualizar la URL incorrecta.

302 Moved Temporarily

El objeto al que se accede ha sido movido a otro lugar de forma temporal. El servidor proporciona, además, la nueva URL en la variable Location de la respuesta. Algunos browsers acceden automáticamente a la nueva URL. El cliente no debe modificar ninguna de las referencias a la URL errónea.

304 Not Modified Cuando se hace un GET condicional, y el documento no ha sido modificado, se devuelve este código de estado.

400 Bad Request La petición tiene un error de sintaxis y no es entendida por el servidor.

401 Unauthorized

La petición requiere una autorización especial, que normalmente consiste en un nombre y clave que el servidor verificará. El campo WWW-Autenticate informa de los protocolos de autentificación aceptados para este recurso.

403 Forbidden Está prohibido el acceso a este recurso. No es posible utilizar una clave para modificar la protección.

404 Not Found La URL solicitada no existe.

500 Internal Server Error

El servidor ha tenido un error interno, y no puede continuar con el procesamiento.

501 Not El servidor no tiene capacidad, por su diseño interno, para

Implemented llevar a cabo el requerimiento del cliente.

502 Bad GatewayEl servidor, que está actuando como Proxy o pasarela, ha encontrado un error al acceder al recurso que había solicitado el cliente.

503 Service Unavailable

El servidor está actualmente deshabilitado, y no es capaz de atender el requerimiento.

Tabla 1 Lista de códigos de estado http

3.4 XML

XML es una sintaxis universal para la descripción y el estructurado de datos independientemente de la lógica de una aplicación. Puede ser utilizado para definir un número ilimitado de lenguajes destinados a aplicaciones específicas. El significado de las tres letras que componen su nombre es eXtensible Markup Language, que significa Lenguaje Extensible de Etiquetado.

La versión 1.0 de XML es una recomendación del W3C (World Wide Web Consortium) publicada en Febrero de 1998, aunque se llevaba trabajando en ella desde dos años antes. Está basada en el anterior estándar SGML (Standard Generalized Markup Language, ISO 8879), que data de 1986, aunque empezó a gestarse a principios de los 70. Éste está a su vez basado en GML, creado por IBM en 1969.

Aunque pueda parecer moderno, sus conceptos están ampliamente asentados y aceptados. Se encuentra además asociado a la recomendación del W3C DOM (Document Object Model), aprobado también en 1998. Éste no es más que un modelo de objetos que, en forma de API, permite acceder a las diferentes partes que pueden componer un documento XML o HTML.

SGML proporciona un modo consistente y preciso de aplicar etiquetas para describir las partes que componen un documento, permitiendo además el intercambio de documentos entre diferentes plataformas. Sin embargo, el problema que se le atribuye es su excesiva dificultad; un indicativo de ella es el hecho de que su recomendación ocupe unas 400 páginas.

De esta forma, manteniendo su misma filosofía, de él se derivó XML como subconjunto simplificado, eliminando las partes más engorrosas y menos útiles. Al igual que sus padres, XML es un metalenguaje: un lenguaje para definir lenguajes. Los elementos que lo componen pueden dar información sobre lo que contienen, no necesariamente sobre su estructura física o presentación, como ocurre en HTML.

Al igual que XML, HTML se también se definió utilizando SGML. En una primera aproximación, las diferencias entre ambos residen en que HTML es simplemente un

lenguaje, mientras que XML un metalenguaje; es decir, se trata de un lenguaje para definir lenguajes. De hecho, mediante XML también se podría definir el HTML.

Desde su creación, ha tenido un crecimiento exponencial. La cantidad de artículos escritos sobre él y el número de aplicaciones compatibles con sus especificaciones se multiplicaron al poco tiempo de aparición. Su importancia queda patente atendiendo al elevado número de importantes compañías que han optado por este nuevo estándar.

XML se propone como lenguaje de bajo nivel (a nivel de aplicación, no de programación) para intercambio de información estructurada entre diferentes plataformas. Se puede usar en bases de datos, editores de texto, hojas de cálculo, y prácticamente cualquier aplicación concebible. Sin ir más lejos, algunos lenguajes, definidos en XML, recorren áreas como la química y la física, las matemáticas, el dibujo, tratamiento del habla, y otras muchas más.

Aplicado en Internet, establece un estándar fijo al que atenerse, y separa el contenido de su presentación. Esto significa que la visualización de documentos Web puede no estar sujeta al estándar de hojas de estilo (CSS) que soporte el navegador ni al lenguaje de script del servidor. Además, con él tampoco habrá de estar atado a la plataforma, pudiendo apreciarse la misma información en dispositivos tan dispares como un PC o un PDA.

Se puede suponer de este modo que XML constituye la capa más baja dentro del nivel de aplicación, sobre el que se puede montar cualquier estructura de tratamiento de documentos, hasta llegar a la presentación.

3.4.1 Conceptos básicos

Uno de los conceptos más relevantes de XML es la distinción entre documentos XML validados y bien formados:

Bien formados: son todos los que cumplen las especificaciones del lenguaje respecto a sus reglas sintácticas, aunque sin estar sujeto a los elementos fijados en un DTD (definición de los elementos que puede haber en el documento XML). De hecho, los documentos XML deben tener una estructura jerárquica muy estricta, la cual deben cumplir los documentos bien formados.

Válidos: Además de estar bien formados, siguen una estructura y una semántica determinada por un DTD. Sus elementos y sobre todo la estructura jerárquica que define el DTD, además de los atributos, deben ajustarse a lo que él dicte.

Como ya se ha mencionado, un DTD es una definición de los elementos que puede haber en el documento XML, así como su relación entre ellos, sus atributos, posibles valores, etc. De hecho DTD significa Document Type Definition, o Definición de Tipo de Documento. Es, en definitiva, una definición de la gramática del documento.

La primera tarea a llevar a cabo cuando se está procesando cualquier información formateada mediante XML es comprobar si está bien formada. Posteriormente, se habrá

de verificar si sigue las reglas gramaticales de un DTD en caso de estar vinculado a alguno. Existen, pues, dos tipos de herramientas para procesar documentos XML: los parsers no validadores, que únicamente comprueban si están bien formados, y los parsers validadores, que verifican que además de bien formado se atiene a su DTD y es válido.

Un documento XML tiene el siguiente aspecto:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ficha>

<nombre>Alberto</nombre><apellidos>Cubo Velazquez</apellidos><direccion>c/Luis Chamizo, 14</direccion>

</ficha>

Aunque es opcional, prácticamente todos los documentos XML comienzan con una línea como la primera. Es la encargada de indicar que lo que la sigue es un documento XML. Puede tener varios atributos (los campos que van dentro de la declaración), algunos obligatorios y otros no:

version: indica la versión de XML usada en el documento; la actual es la 1.0. Es obligatorio ponerlo, a no ser que sea un documento externo a otro que ya lo incluía.

encoding: señala la forma en que se ha codificado el documento. Cualquier valor está permitido, y depende del parser el entender o no la codificación. Por defecto es UTF-8, aunque existen otras, como UTF-16, US-ASCII, ISO-8859-1, etc. No es obligatorio salvo que se trate de un documento externo a otro principal.

standalone: indica si el documento va acompañado de un DTD (no), o no lo necesita (yes). Su presencia no es necesaria, ya que más tarde se indicará el DTD en caso de ser necesario.

En cuanto a la sintaxis del documento, y antes de entrar en el estudio de las etiquetas, hay que resaltar algunos detalles de gran importancia:

Los documentos XML son sensibles a mayúsculas. Es decir, en ellos se diferencia las mayúsculas de las minúsculas. Por ello <FICHA> sería una etiqueta diferente a <ficha>.

Además todos los espacios y retornos de carro se tienen en cuenta (dentro de las etiquetas, en los elementos).

Hay algunos caracteres especiales reservados, que forman parte de la sintaxis de XML: <, >, &, " y '. En su lugar, cuando se desee representarlos habrá que usar las entidades &lt;, &gt;, &amp;, &quot; y &apos; respectivamente.

Los valores de los atributos de todas las etiquetas deben ir siempre entrecomillados. Son válidas las dobles comillas (") y la comilla simple (').

Analizando el contenido, se observan una serie de etiquetas que contienen datos. Cabe señalar la diferencia existente entre los conceptos de elemento y etiqueta: los elementos son las entidades en sí, lo que tiene contenido, mientras que las etiquetas sólo describen a los elementos. Un documento XML está compuesto por elementos, y en su sintaxis éstos se nombran mediante etiquetas.

Existen dos tipos de elementos: los vacíos y los no vacíos. Hay varias consideraciones importantes a tener en cuenta al respecto:

Toda etiqueta no vacía debe tener una etiqueta de cerrado: <etiqueta> debe estar seguida de </etiqueta>. Esto se hace para evitar posibles errores de interpretación.

Todos los elementos deben estar perfectamente anidados. No está permitido lo que se expone en el siguiente ejemplo:

<ficha><nombre>Alberto</ficha></nombre>

Los elementos vacíos son aquellos que no tienen contenido dentro del documento. Un ejemplo en HTML son las imágenes. La sintaxis correcta para estos elementos implica que la etiqueta tenga siempre esta forma: <etiqueta/>.

Hasta aquí llega esta reducida introducción a la sintaxis XML. Aunque la especificación íntegra es más extensa en cuanto a detalles sintácticos, codificaciones, etc., con lo expuesto hasta ahora es más que suficiente para el alcance del presente proyecto.

3.4.2 DTD: Definición de Tipos de Documentos

Tal y como se comentó con anterioridad, los documentos XML puede ser válidos o bien formados. Con respecto a los primeros, también se mencionó que su gramática está definida en los DTD.

Los DTD no son más que definiciones de los elementos que puede incluir un documento XML, de la forma en que deben hacerlo (qué elementos van dentro de otros) y los atributos que se les puede dar. Normalmente la gramática de un lenguaje se define mediante notación EBNF, que es bastante engorrosa. DTD hace lo mismo pero de un modo más intuitivo.

Hay varios modos de hacer referencia a un DTD en un documento XML:

Incluir dentro del documento una referencia al documento DTD en forma de URI (Universal Resource Identifier, o Identificador Universal de Recursos) y mediante la siguiente sintaxis:

<!DOCTYPE ficha SYSTEM “http://www.url_prueba/~acubo/DTD/ficha.dtd”>

En este caso, la palabra SYSTEM indica que el DTD se obtendrá a partir de un elemento externo al documento e indicado por el URI que lo sigue.

Incluir el DTD dentro del propio documento:

<?xml version=”1.0”?><!DOCTYPE ficha [<!ELEMENT ficha (nombre+, apellido+, direccion+, foto?)><!ELEMENT nombre (#PCDATA)><!ATTLIST nombre sexo (masculino | femenino) #IMPLIED><!ELEMENT apellidos (#PCDATA)><!ELEMENT direccion (#PCDATA)><!ELEMENT foto EMPTY>]><ficha>

<nombre>Alberto</nombre><apellidos>Cubo Vlezquez</apellidos><direccion>c/Luis Chamizo, 14</direccion>

</ficha>

La forma de incluir el DTD directamente como en este ejemplo pasa por añadir a la declaración <!DOCTYPE y después el nombre del tipo de documento, en vez de la URI del DTD, el propio DTD entre los símbolos '[' y ']'. Todo lo que hay entre ellos será considerado parte del DTD.

En cuanto a la definición de los elementos, tiene la virtud de ser bastante intuitiva: tras la cláusula <!ELEMENT se incluye el nombre del elemento (el que luego se indicara en la etiqueta), y después, en función del elemento:

Entre paréntesis, si el elemento no está vacío, se indica el contenido que puede tener el elemento: la lista de elementos hijos o que descienden de él si los tiene, separados por comas; o el tipo de contenido, normalmente #PCDATA, que indica datos de tipo texto, que son los más habituales.

Si es un elemento vacío, se indica con la palabra EMPTY.

A la hora de indicar los elementos descendientes (los que están entre paréntesis) vemos que van seguidos de unos caracteres especiales: '+', '*', '?' y '|'. Sirven para indicar qué tipo de uso se permite hacer de esos elementos dentro del documento:

+: uso obligatorio y múltiple; permite uno o más elementos de ese tipo dentro del elemento padre, pero como mínimo uno.

*: opcional y múltiple; puede no haber ninguna ocurrencia, una o varias.

?: opcional pero singular; puede no haber ninguno o como mucho uno.

|: equivale a un OR, es decir, da la opción de usar un elemento de entre los que forman la expresión, y solo uno.

De este modo, si por ejemplo existe en un DTD la declaración:

<!ELEMENT ficha (nombre+, apellidos+, direccion*, foto?, telefono*|fax*)>

Se sabrá del elemento ficha que puede contener los siguientes elementos: un nombre y unos apellidos como mínimo, pero puede tener más de uno de cada; opcionalmente puede incluirse una o varias direcciones, pero no es obligatorio; opcionalmente también se puede incluir una única foto; y por fin, pueden incluirse, aunque no es obligatorio en ninguno de los dos casos, uno o más teléfonos o uno o más números de fax.

Como ya se comentó, un documento XML presenta una jerarquía muy determinada, definida en el DTD si es un documento válido, pero siempre inherente al documento en cualquier caso (siempre se puede inferir esa estructura a partir del documento sin necesidad de tener un DTD en el que basarse), con lo que se puede representar como un árbol de elementos. Existe un elemento raíz, que siempre debe ser único (sea nuestro documento válido o sólo bien formado) y que se llamará como el nombre que se ponga en la definición del <!DOCTYPE si está asociado a un DTD o cualquiera que se desee en caso contrario. Y de él descienden las ramas de sus respectivos elementos descendientes o hijos. De este modo, la representación en forma de árbol de nuestro documento XML de ejemplo sería el indicado en la Figura [5]

Figura 5: Jerarquía del documento ejemplo XML

Se observa que se trata de un documento muy sencillo, con una profundidad de 2 niveles nada más: el elemento raíz ficha, y sus hijos nombre, apellido, dirección, y foto. Es obvio que cuanta más profundidad, mayor tiempo se tarda en procesar el árbol, pero la dificultad siempre será la misma gracias a que se usan como en todas las estructuras de árbol algoritmos recursivos para tratar los elementos.

El DTD, por ser precisamente la definición de esa jerarquía, describe la forma del árbol. La diferencia (y la clave) está en que el DTD define la forma del árbol de elementos, y un documento XML válido puede basarse en ella para estructurarse, aunque no tienen que tener en él todos los elementos, si el DTD no obliga a ello. Un documento XML bien formado sólo habrá de tener una estructura jerarquizada, pero sin tener que ajustarse a ningún DTD concreto.

Para la definición de los atributos, se usa la declaración <!ATTLIST seguida de:

El nombre de elemento del que se está declarando los atributos.

El nombre del atributo.

Los posibles valores del atributo, entre paréntesis y separados por el carácter |. Al igual que para los elementos, significa que el atributo puede tener uno y sólo uno de los valores incluidos entre paréntesis. O bien, si no hay valores definidos, se escribe CDATA para indicar que puede ser cualquier valor alfanumérico. También podemos indicar con la declaración ID que el valor alfanumérico que se le de será único en el documento, y se podrá hacer referencia a ese elemento a través del atributo y valor.

De forma opcional y entrecomillado, un valor por defecto del atributo si no se incluye otro en la declaración.

Por último, si es obligatorio cada vez que se usa el elemento en cuestión declarar este atributo, es necesario declararlo con la cláusula #REQUIRED; si no lo es, se debe poner #IMPLIED, o bien #FIXED si el valor de dicho atributo se debe mantener fijo a lo largo de todo el documento para todos los elementos del mismo tipo.

Cabe destacar un aspecto de cara a la optimización del diseño de DTDs. En muchas ocasiones es necesario decidir entre especificar atributos de los elementos como elementos descendientes o como atributos en sí mismos. Suponiendo una pieza de maquinaria con unas características determinadas, las cuales se pueden representar de las siguientes formas:

<pieza>MiPieza<color>Rojo</color>

</pieza>

<pieza color="Rojo">MiPieza</pieza>

En la primera forma, el procesador tiene que bajar al siguiente nivel del árbol de elementos para saber el color de MiPieza, mientras que en el segundo caso lo puede obtener haciendo referencia directamente el atributo color del elemento en el que estás.

Existen multitud de desarrolladores que prefieren el primer modo por estar más acorde con la filosofía de XML. Según ella, las etiquetas hacen referencia siempre a su contenido, sin necesidad de acudir al uso de atributos como se hace en HTML.

3.4.3 Entidades

Mediante estos elementos especiales es posible dotar de modularidad a los documentos XML. Se pueden definir, del mismo modo que los ya mencionados DTDs, dentro del mismo documento XML o en DTDs externos.

Anteriormente, se han mencionado los caracteres especiales &, ", ', < y >. Se trata de entidades que han de escribirse mediante las declaraciones: &amp;, &quot;, &apos;, &lt; y &gt;. Es decir, que cuando se desee hacer referencia alguna entidad definida dentro de un mismo documento o en otro externo, se debe utilizar la sintaxis &nombre;.

Existe un conjunto de entidades predefinidas de caracteres ISO. Sin embargo, las entidades no solo sirven para incluir caracteres especiales no ASCII. También se pueden usar para incluir cualquier documento u objeto externo al documento propio.

Por ejemplo, y como uso más simple, se puede crear en un DTD o en el documento XML una entidad que haga referencia a un nombre largo:

<!ENTITY DAT “Delegación de Alumnos de Telecomunicaciones”

De esta forma, cada vez que se desee que en un documento aparezca el nombre “Delegación de Alumnos de Telecomunicaciones”, bastará con escribir &DAT;. Se trata de un sencillo método cuyos beneficios son claros.

El texto al que se hace referencia mediante la entidad puede ser de cualquier tamaño y contenido. Si se desea incluir una porción de otro documento muy largo que haya sido guardado aparte, de tipo XML o cualquier otro, se puede hacer de este modo:

<!ENTITY midoc SYSTEM http://www.url_prueba/~acubo/DTD/ficha.dtd >

Del mismo modo que con los DTDs externos, se indica al procesador con SYSTEM que la referencia es externa y que lo que sigue es una URI estándar, y es lo que queda entrecomillado a continuación. Lo expuesto hasta ahora se aplica dentro de documentos XML, pero no de DTDs. Para incluir entidades en DTDs se debe emplear el carácter %:

<!ENTITY % uno “(uno | dos | tres) ” >

Y para expandirlo en un DTD habrá que escribir:

<!ELEMENT numero (%uno;) #IMPLIED>

3.4.4 Modelo de Objetos de Documentos: DOM

El modelo de objetos de documentos del W3C, o Document Object Model (DOM) es una representación interna estándar de la estructura de un documento, y proporciona un interfaz al programador (API) para poder acceder de forma fácil, consistente y homogénea a sus elementos, atributos y estilo. Es un modelo independiente de la plataforma y del lenguaje de programación.

El W3C establece varios niveles de actuación, coincidiendo con el tiempo en que se presentan como recomendación:

Nivel 1: se refiere a la parte interna, y modelos para HTML y XML. Contiene funcionalidades para la navegación y manipulación de documentos. Tiene 2 partes: el core o parte básica, referida a documentos XML, y la parte HTML, referida precisamente a los HTML.

Nivel 2: incluye un modelo de objetos e interfaz de acceso a las características de estilo del documento, definiendo funcionalidades para manipular la información sobre el estilo del mismo. También incluirá un modelo de eventos para soportar los espacios de nombres XML y consultas enriquecidas.

Posteriores niveles especificarán interfaces a posibles sistemas de ventanas, manipulación de DTD y modelos de seguridad.

El objetivo es que de una vez por todas cualquier script pueda ejecutarse de forma más o menos homogénea en cualquier navegador que soporte dicho DOM. Tener una plataforma estándar en la que poder crear contenidos sin temor a no estar soportado por alguna marca o versión de navegador, que además sea potente y versátil.

Y por supuesto, como el conjunto de piezas que el W3C está creando para su uso en el intercambio de documentos e información, no estará sujeto al ámbito de los navegadores, sino que su uso será extensible a cualquier tipo de aplicación que acceda a esos documentos.

3.5 Conclusiones

En este capítulo se han expuesto los conocimientos básicos que son necesarios para poder abordar REST y SOAP de manera eficaz. Se han estudiado los conceptos de localizador de recursos (URL y UUID), protocolo de transferencia (HTTP) y lenguaje de marcas para describir y estructurar los datos (XML). En el siguiente capítulo se verá

la arquitectura de Servicios Web SOAP y el lenguaje de descripción de Servicios WSDL. Este estudio será necesario para poder realizar comparaciones entre REST y SOAP.

4 SOAP Y WSDL

En este capítulo se van se va a ver la arquitectura de Servicios Web SOAP y el lenguaje de descripción de Servicios WSDL. Este estudio será necesario para poder realizar comparaciones entre REST y SOAP.

4.1 SOAP

Actualmente un sin fin de empresas se han decantado por el desarrollo de aplicaciones que puedan trabajar sobre Internet porque permite la distribución global de la información. Las tecnologías más usadas para el desarrollo de estas aplicaciones, han sido hasta hace poco CORBA, COM y EJB. Cada una proporciona un marco de trabajo basado en la activación de objetos remotos mediante la solicitud de ejecución de servicios de aplicación a un servidor de aplicaciones.

Estas tecnologías han demostrado ser muy efectivas para el establecimiento de sitios Web, sin embargo presentan una serie de desventajas, como son total incompatibilidad e interoperabilidad entre ellas, total dependencia de la máquina servidora sobre la que corren, así como el lenguaje de programación.

Esto ha llevado a la necesidad de considerar un nuevo modelo de computación distribuida de objetos que no sea dependiente de plataformas, modelos de desarrollo ni lenguajes de programación. Por todos estos motivos surge el concepto de SOAP (Simple Object Access Protocol).

4.1.1 Concepto de SOAP

La funcionalidad que aporta SOAP es la de proporcionar un mecanismo simple y ligero de intercambio de información entre dos puntos usando el lenguaje XML. SOAP no es más que un mecanismo sencillo de expresar la información mediante un modelo de empaquetado de datos modular y una serie de mecanismos de codificación de datos. Esto permite que SOAP sea utilizado en un amplio rango de servidores de aplicaciones que trabajen mediante el modelo de comunicación RPC (Remote Procedure Call).

SOAP consta de tres partes:

• El SOAP envelope que define el marco de trabajo que determina qué se puede introducir en un mensaje, quién debería hacerlo y si esa operación es opcional u obligatoria.

• Las reglas de codificación SOAP que definen el mecanismo de serialización que será usado para encapsular en los mensajes los distintos tipos de datos.

• La representación SOAP RPC que define un modo de funcionamiento a la hora de realizar llamadas a procedimientos remotos y la obtención de sus resultados.

4.1.2 Objetivos de SOAP

A la hora de realizar el diseño de SOAP se han tenido en cuenta una serie de consideraciones con el fin de cumplir una serie de objetivos claros, objetivos que le darán el potencial que reside en SOAP y que le harán tan atractivo. Estos objetivos son:

• Establecer un protocolo estándar de invocación a servicios remotos que esté basado en protocolos estándares de uso frecuente en Internet, como son HTTP

(Hiper Text Transport Protocol) para la transmisión y XML (eXtensible Markup Language) para la codificación de los datos.

• Independencia de plataforma hardware, lenguaje de programación e implementación del servicio Web.

El logro de estos objetivos ha hecho de SOAP un protocolo extremadamente útil, ya que el protocolo de comunicación HTTP es el empleado para la conexión sobre Internet, por lo que se garantiza que cualquier cliente con un navegador estándar pueda conectarse con un servidor remoto. Además, los datos en la transmisión se empaquetan o serializan con el lenguaje XML, que se ha convertido en algo imprescindible en el intercambio de datos ya que es capaz de salvar las incompatibilidades que existían en el resto de protocolos de representación de datos de la red.

Por otra parte, los servidores Web pueden procesar las peticiones de usuario empleando tecnologías tales como Servlets, páginas ASP (Active Server Pages), páginas JSP (Java Server Pages) o sencillamente un servidor de aplicaciones con invocación de objetos mediante CORBA, COM o EJB.

Un ejemplo típico de diseño de un servicio Web utilizando las ventajas de SOAP podría ser el mostrado en la Figura [6].

Figura 6: Ejemplo de uso de SOAP

La especificación SOAP (SOAP Specification 1.1) indica que las aplicaciones deben ser independientes del lenguaje de desarrollo, por lo que las aplicaciones cliente y servidor pueden estar escritas con HTML, DHTML, Java, Visual Basic o cualquier otra herramienta o lenguaje disponibles.

4.1.3 Un ejemplo sencillo de mensajes SOAP

Supongamos que tenemos un servicio Web el cual contiene una relación de productos junto con una serie de características de éstos, y supongamos que le queremos hacer una consulta acerca del precio de uno de los productos cuyo código es RHAT, el código relativo a la petición de consulta en lenguaje SOAP sería:

<?xml version="1.0"?><SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<getQuote xmlns="http://namespaces.cafeconleche.org/xmljava/ch2/"><symbol>RHAT</symbol>

</getQuote>

</SOAP-ENV:Body></SOAP-ENV:Envelope>

Como respuesta a esta petición vendría de vuelta el siguiente mensaje en el que se le dice que el precio del producto pedido es 4.12:

<?xml version="1.0"?><SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<Quote xmlns="http://namespaces.cafeconleche.org/xmljava/ch2/"><Price>4.12</Price>

</Quote>

</SOAP-ENV:Body></SOAP-ENV:Envelope>

4.1.3.1 Partes de un mensaje SOAP

Un mensaje SOAP no es más que un documento en formato XML que está constituido por tres partes bien definidas que son: el SOAP envelope, el SOAP header de carácter opcional y el SOAP body. Cada uno de estos elementos contiene lo siguiente:

• El envelope es el elemento más importante y de mayor jerarquía dentro del documento XML y representa al mensaje que lleva almacenado dicho documento.

• El header es un mecanismo genérico que se utiliza para añadir características adicionales al mensaje SOAP. El modo en la que se añadan cada uno de los campos dependerá exclusivamente del servicio implementado entre cliente y servidor, de forma que cliente y servidor deberán estar de acuerdo con la jerarquía con la que se hayan añadido los distintos campos. De esta forma será sencillo separar entre sí los distintos datos a transmitir dentro del mensaje.

• El body es un contenedor de información en el cual se almacenarán los datos que se quieran transmitir de lado a lado de la comunicación. Dentro de este campo, SOAP define un elemento de uso opcional denominado Fault utilizado en los mensajes de respuesta para indicar al cliente algún error ocurrido en el servidor.

Un ejemplo de uso del header, donde se indica un cierto parámetro útil para el servicio Web que le indica como debe procesar el mensaje sería:

<?xml version="1.0"?><SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP- ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Header><t:Transaction xmlns:t="some-URI" SOAP-

ENV:mustUnderstand="1">5

</t:Transaction></SOAP-ENV:Header>

<SOAP-ENV:Body><getQuote xmlns=

"http://namespaces.cafeconleche.org/xmljava/ch2/"><symbol>RHAT</symbol>

</getQuote></SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Un ejemplo de uso del nuevo elemento body sería el siguiente, en el que se ha detectado un error en la aplicación que corre sobre el servidor que provoca que no opere convenientemente, por lo que se le indica al cliente:

<?xml version="1.0"?><SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

<SOAP-ENV:Fault><faultcode>SOAP-ENV:Server</faultcode>

<faultstring>Server Error</faultstring>

</SOAP-ENV:Fault>

</SOAP-ENV:Body></SOAP-ENV:Envelope>

El atributo encodingStyle se utiliza para indicar las reglas de serialización utilizadas en el 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. De entre todas las posibles, las más utilizadas son:

http://schemas.xmlsoap.org/soap/encoding/ y http://my.host/encoding/restricted http://my.host/encoding/.

Todo mensaje SOAP debe tener un elemento Envelope asociado a la dirección de red http://schemas.xmlsoap.org/soap/envelope/. Si un mensaje recibido por una aplicación SOAP contiene en este elemento un valor distinto al anterior la aplicación trataría dicho mensaje como erróneo.

4.1.4 Serialización

A la hora de introducir los datos en un mensaje SOAP existen una serie de normas a tener en cuenta. De esta forma SOAP define una serie de tipos básicos que serán empaquetados de forma directa y una serie de mecanismos para empaquetar tipos complejos y estructurados formados por elementos simples.

En un inicio, SOAP consideró un conjunto de tipos como tipos simples con el fin de realizar un mapeo directo entre el propio documento SOAP y tipos básicos de Java. Ahora bien, actualmente este conjunto ha aumentado notablemente de forma que existe un número bastante grande de tipos que gozan de esta situación. De entre todos ellos destacan los indicados en la Figura [7].

TIPOS SOAP TIPOS JAVA

SOAP-ENC:int Java.lang.IntegerSOAP-ENC:long Java.lang.Long

SOAP-ENC:short Java.lang.ShortSOAP-ENC:string Java.lang.StringSOAP-ENC:bolean Java.lang.BooleanSOAP-ENC:flota Java.lang.FloatSOAP-ENC:double Java.lang.DoubleSOAP-ENC:byte Java.lang.Byte

Tabla 2 Mapeo entre tipos SOAP y JAVA

Además de todos estos tipos sencillos, SOAP implementa una serie de mecanismos para serializar tipos complejos con elementos simples en su interior. De esta forma tenemos:

• Structs

Un struct no es más que un elemento que contiene un conjunto de elementos hijos almacenados cada uno de ellos en un campo propio. Un ejemplo podría ser:

<Quote xmlns="http://namespaces.cafeconleche.org/xmljava/ch2/"><Symbol>RHAT</Symbol><Price>4.12</Price>

</Quote>

En términos de Java tendríamos un objeto de tipo Quote dentro del cual hay dos elementos sencillos: uno de tipo String llamado Symbol y el otro de tipo double y de nombre Price. Es decir:

public class Quote {

public String Symbol();public double Price();

}

• Arrays

Un array en un mensaje SOAP es representado mediante un elemento cuyo tipo es SOAP-ENC:Array.

Aunque en Java sea obligatorio que dentro de un array haya únicamente elementos del mismo tipo, SOAP no presenta esta restricción, sino que es posible albergar elementos de distintos tipos, así un ejemplo sería:

<Bid xsi:type="SOAP-ENC:Array"><Symbol xsi:type="xsd:token">RHAT</Symbol><Price xsi:type="xsd:double">4.12</Price><Account xsi:type="xsd:string">777-7777</Account>

</Bid>

Si quisiésemos restringir explícitamente el tipo de los elementos almacenados en el array podríamos hacerlo de la forma:

<Bid xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="xsd:double[3]">

<Price>4.52</Price><Price>0.35</Price><Price>34.68</Price>

</Bid>

En SOAP también es posible implementar arrays bidimensionales, incluso arrays que almacenan strings. Un ejemplo de esto sería:

<SOAP-ENC:Array SOAP-ENC:arrayType="xsd:double[3,2]"><SOAP-ENC:double>1.1</SOAP-ENC:double><SOAP-ENC:double>1.2</SOAP-ENC:double><SOAP-ENC:double>2.1</SOAP-ENC:double><SOAP-ENC:double>2.2</SOAP-ENC:double><SOAP-ENC:double>3.1</SOAP-ENC:double><SOAP-ENC:double>3.2</SOAP-ENC:double>

</SOAP-ENC:Array>

Este mismo Array que hemos explicado su realización en SOAP, en tecnología Java sería de la manera:

double[][] array = {{1.1, 1.2},{2.1, 2.2},{3.1, 3.2}

}

O un ejemplo algo más complicado sería un Array que contiene a su vez dos arrays cada uno de los cuales contiene a su vez un Array de Strings:

<SOAP-ENC:Array SOAP-ENC:arrayType="xsd:string[][2]"><item href="#array-1"/><item href="#array-2"/>

</SOAP-ENC:Array>

<SOAP-ENC:Array id="array-1" SOAP-ENC:arrayType="xsd:string[2]"><item>r1c1</item><item>r1c2</item><item>r1c3</item>

</SOAP-ENC:Array>

<SOAP-ENC:Array id="array-2" SOAP-ENC:arrayType="xsd:string[2]">

<item>r2c1</item><item>r2c2</item>

</SOAP-ENC:Array>

4.1.5 Protocolo HTTP mediante SOAP

Una de las funcionalidades con las que cuenta SOAP y que lo hace extremadamente atractivo es el envío de mensajes SOAP vía protocolo HTTP, todo ello realizado de forma directa por medio de las librerías de SOAP.

Este hecho provoca que existen ciertas diferencias entre un mensaje SOAP normal y uno enviado haciendo uso del protocolo HTTP. De esta forma deben cumplirse dos aspectos:

• El HTTP header del mensaje de petición al servicio Web debe contener un campo SOAPAction. El campo SOAPAction alerta a los servidores Web y firewalls por los que pase de que el mensaje contiene documento SOAP, esto facilita a dichos firewalls el filtrado de las peticiones SOAP sin necesidad de tener que explorar el contenido del body del mensaje.

• Si la petición SOAP al servicio Web falla, el servidor debe devolver en el mensaje de respuesta un error del tipo HTTP 500 Internal Server Error en vez de un 200 OK que se envía cuando todo ha ido bien.

Un ejemplo de todo esto sería el siguiente extracto de código en el que lanza una petición HTTP de tipo POST contra un Servlet que corre en la dirección Web www.ibiblio.org bajo el control del usuario de nombre elharo:

POST /xml/cgi-bin/SOAPHandler HTTP/1.1Content-Type: text/xml; charset="utf-8"Content-Length: 267SOAPAction: "http://www.ibiblio.org/#elharo"

<?xml version="1.0"?><SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" >

<SOAP-ENV:Body><getQuote

xmlns="http://namespaces.cafeconleche.org/xmljava/ch2/"><symbol>RHAT</symbol>

</getQuote></SOAP-ENV:Body>

</SOAP-ENV:Envelope>

El servidor envía la respuesta de vuelta al cliente y después cierra la conexión. Como cualquier otra respuesta HTTP el mensaje SOAP empieza con el código de retorno HTTP. Suponiendo que la petición tuvo éxito y no ocurrió ningún error en el servidor, el mensaje de respuesta sería:

HTTP/1.0 200 OKContent-Type: text/xml; charset="utf-8"Content-Length: 260

<?xml version="1.0"?><SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

<SOAP-ENV:Body><Quote xmlns="http://namespaces.cafeconleche.org/xmljava/ch2/">

<Price>4.12</Price></Quote>

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

4.2 WSDL

En este apartado se verá el lenguaje de descripción de Servicios Web WSDL 1.1 [5], cuya especificación completa [WSDL 1.1] puede encontrarse en el W3C.

El esquema XML por sí solo no puede describir totalmente un Servicio Web. A continuación se verá un ejemplo en el que se supone que se ha creado un servicio Web Calculadora. Este servicio Web expone los métodos sumar y restar. Ambos métodos aceptan dos enteros y devuelven un único entero con el resultado; sumar devuelve la suma de los dos enteros y restar devuelve su diferencia.

En un esfuerzo para describir cómo interacciona un cliente con el servicio Web se define un esquema para los mensajes que se intercambiarán entre el cliente y el servidor. El esquema contiene una definición de un tipo de complejo para los mensajes

de petición y repuesta para los métodos sumar y restar. Recordemos que el objetivo último es que los desarrolladores no tengan que investigar en las definiciones del esquema intentando descifrar cómo interaccionar con el servicio Web. En lugar de ello se quiere describir el servicio de forma que una herramienta pueda descifrarlo y crear un proxy por el cliente.

Además de la información que proporciona el esquema, ¿Qué más necesita conocer el cliente para invocar los métodos que expone el Servicio Web Calculadora? Como el cuerpo de un mensaje de SOAP puede contener cualquier cosa que no invalide el XML los mensajes de SOAP se pueden combinar para disponer de una amplia variedad de patrones de intercambio de mensajes. Los patrones de intercambio de mensajes para el Servicio Web Calculadora son bastante inmediatos pero una asociación formal entre los mensajes de petición Sumar y Restar y sus mensajes de respuesta asociados eliminarían cualquier posible ambigüedad.

Una descripción formal de los patrones de mensaje resulta aún más importante en el caso de Servicio Web más complejos. Algunos servicios podrían aceptar una petición pero no enviar la respuesta correspondiente devuelta al cliente. Otros podrían solamente enviar mensajes al cliente. Además, el esquema no contiene información sobre cómo acceder al Servicio Web. Como SOAP es independiente del protocolo, se intercambiarán los mensajes entre el cliente y el servidor de numerosas formas. ¿Cómo se sabe si hay que enviar un mensaje mediante HTTP, SMTP o cualquier otro protocolo de transporte? Más aún, ¿cómo se sabe la dirección la que hay que enviar el mensaje?

El lenguaje de descripción de servicios Web (WSDL, Web Service Description Language) es un dialecto basado en XML sobre el esquema que describe un servicio Web. Un documento WSDL proporciona la información necesaria al cliente para interaccionar con el servicio Web. WSDL es extensible y se pude utilizar para describir, prácticamente, cualquier servicio de red, incluyendo SOAP sobre HTTP e incluso protocolos que no se basan en XML como DCOM sobre UDP.

Figura 7: Esquema WSDL

Dado que los protocolos de comunicaciones y los formatos de mensajes están estandarizados en la comunidad del Web, cada día aumenta la posibilidad e importancia de describir las comunicaciones de forma estructurada. WSDL afronta esta necesidad definiendo una gramática XML que describe los servicios de red como colecciones de puntos finales de comunicación capaces de intercambiar mensajes. Las definiciones de servicio de WSDL proporcionan documentación para sistemas distribuidos y sirven como fórmula para automatizar los detalles que toman parte en la comunicación entre aplicaciones.

Los documentos WSDL definen los servicios como colecciones de puntos finales de red o puertos. En WSDL, la definición abstracta de puntos finales y de mensajes se separa de la instalación concreta de red o de los enlaces del formato de datos. Esto permite la reutilización de definiciones abstractas: mensajes, que son descripciones abstractas de los datos que se están intercambiando y tipos de puertos, que son colecciones abstractas de operaciones. Las especificaciones concretas del protocolo y del formato de datos para un tipo de puerto determinado constituyen un enlace reutilizable. Un puerto se define por la asociación de una dirección de red y un enlace reutilizable; una colección de puertos define un servicio. Por esta razón, un documento WSDL utiliza los siguientes elementos en la definición de servicios de red:

Types: contenedor de definiciones del tipo de datos que utiliza algún sistema de tipos (por ejemplo XSD).

Message: definición abstracta y escrita de los datos que se están comunicando. Operation: descripción abstracta de una acción admitida por el servicio. Port Type: conjunto abstracto de operaciones admitidas por uno o más puntos

finales. Binding: especificación del protocolo y del formato de datos para un tipo de

puerto determinado. Port: punto final único que se define como la combinación de un enlace y una

dirección de red. Service: colección de puntos finales relacionados.

A continuación se detalla un poco más en profundidad cada uno de estos elementos

Elemento_ Types:

El elemento Types contiene información de esquema referenciado en el documento WSDL. El sistema de tipos predeterminado que admite WSDL es de esquema de XML. Si se usa esquema de XML para definir los tipos que contiene el elemento Types, el elemento schema aparecerá inmediatamente como elemento hijo. Se pueden utilizar otros sistemas de tipos por extensión. Si se desea utilizar otro sistema de tipo puede aparecer un elemento de extensibilidad bajo el elemento Types. El nombre de este elemento debería identificar el sistema de tipos utilizados. En este capítulo se limitará a tratar el esquema de XML porque es el sistema de tipos dominante en los documentos WSDL.

Elemento message :

El elemento Message proporciona una abstracción común para el paso de mensajes entre el cliente y el servidor. Como puede utilizar múltiples formatos de de definición de esquema en documento WSDL es necesario disponer de un mecanismo común para identificar los mensajes. El elemento Message proporciona este nivel común de abstracción al que se hará referencia en otras partes del documento WSDL.

Puede aparecer, y normalmente aparecerán, múltiples elementos Message en un documento WSDL, uno para cada mensaje que se comunica entre el cliente y el servidor. Cada mensaje contiene uno o más elementos "Part" que describen las piezas del contenido del mensaje. Un ejemplo de una parte es el cuerpo de un mensaje de SOAP o un parámetro que forma parte de una cadena de petición, un parámetro codificado en el cuerpo del mensaje de SOAP o todo el cuerpo de un mensaje de SOAP.

Elemento PortType :

El elemento PorType contiene un conjunto de operaciones abstractas que representan los tipos de correspondencia que pueden producirse entre el cliente y el servidor. Para los Servicios Web de estilo RPC se puede pensar en un PorType como una definición en donde cada método se puede definir como una operación. Un tipo puerto se compone de un conjunto de elementos Operation que define una determinada acción. Los elementos Operation se componen de mensajes definidos en el documento WSDL. WSDL define cuatro tipos de operaciones denominadas tipo operaciones:

Request-response (petición-respuesta): Comunicación del tipo RPC en la que le cliente realiza una petición y el servidor envía la correspondiente respuesta.

One-way (un-sentido): Comunicación del estilo documento en la que el cliente envía un mensaje pero no recibe una respuesta del servidor indicando el resultado del mensaje procesado.

Solicit-response (solicitud-respuesta): La contraria a la operación petición-respuesta. El servidor envía una petición y el cliente le envía de vuelta una respuesta.

Notification (Notificación): La contraria a la operación un-sentido el servidor envía una comunicación del estilo documento al cliente.

Elemento Binding :

El elemento Binding contiene las definiciones de la asociación de un protocolo como SOAP a un determinado BindingType. Las definiciones Binding especifican detalles de formatos del mensaje y el protocolo. Por ejemplo, la información de asociación especifica si se puede acceder a una instancia de un PortType de forma RPC.

Las definiciones Binding también indican el número de comunicaciones de red que se requieren para realizar una determinada acción. Por ejemplo, una llamada RPC de SOAP sobre HTTP podría involucrar un intercambio de comunicación HTTP, pero esa

misma llamada sobre SMTP podría involucrar dos intercambios de comunicaciones de SMTP discretas. La asociación se logra utilizando elementos de extensión. Cada protocolo tiene su propio conjunto de elementos de extensión para especificar los detalles del protocolo y el formato de los mensajes. Para un determinado protocolo los elementos de extensión se suelen utilizar para decorar las acciones individuales de una operación y la propia operación con la información de asociación del protocolo. A veces los elementos de extensión se utilizan en el propio nivel PortType.

Elemento Service :

Un servicio es un grupo de puertos relacionados y se definen en el elemento Service. Un puerto es un extremo concreto de un Servicio Web al que se hace referencia por una dirección única. Los puertos que se definen en determinado servicio son independientes. Por ejemplo, la salida de un puerto que no puede utilizarse como una entrada de otro.

Elemento Extensibilidad :

Los elementos de Extensibilidad se utilizan para representar determinadas tecnologías. Por ejemplo, se puede utilizar los elementos de extensibilidad para especificar el idioma en que se utiliza en el esquema de los elementos Types.

El esquema para un determinado conjunto de elementos de extensibilidad se debe definir dentro de distintos espacios de nombres que WSDL. La definición de los propios elementos puede contener un atributo wsdl:required que indique un valor boolean si el atributo Requiered se establece a “TRUE”. En una definición de elementos una asociación que haga referencia a ese conjunto concreto de electos de extensibilidad tiene que incluir dicho elemento.

Lo más habitual es que los elementos de extensibilidad se utilicen para especificar especificación de asociación. La especificación WSDL define conjunto de elementos de extensibilidad para la asociación SOAP, HTTP GET, HTTP POS, MIME. Sin embargo, la especificación sólo define las asociaciones para dos de los cuatro tipos de operaciones. Un sentido y petición repuesta.

4.3 Conclusiones

En este capítulo se ha visto la arquitectura de Servicios Web SOAP y el lenguaje de descripción de Servicios WSDL. En el siguiente capítulo se estudiará ampliamente REST, que se presenta como una alternativa a SOAP en el mundo de los Servicios Web.

5 REPRESENTATIONAL STATE TRANSFER: REST

En este capítulo queda recogida una visión actual del estilo de arquitectura REST. La base del capítulo es la [disertación] de Roy Thomas Fielding, aunque también añade algunos detalles del funcionamiento que surgieron posteriormente.

5.1 Introducción

REST son las siglas de Representational State Transfer, un estilo de arquitectura especialmente diseñado para los sistemas distribuidos de hipermedios cuyo término acuñó Roy Thomas Fielding en su disertación.

La motivación de desarrollar REST era crear un modelo de arquitectura que describiese como debería funcionar la Web, así como que pudiese servir como marco de trabajo para los estándares de protocolos Web. REST ha sido aplicado para describir la

arquitectura Web deseada, ayudar a identificar problemas existentes, comparar soluciones alternativas, y asegurar que el protocolo no viole las restricciones que hacen que la Web funcione correctamente. Este trabajo fue realizado por el Internet Engineering Taskforce (IETF) y el World Wide Web Consortium (W3C), gracias a sus esfuerzos por definir un estándar de arquitectura para la Web: HTTP, URI y HTML.

Desde un punto de vista cronológico, REST ha ido evolucionando. Roy Thomas Fielding lo concibió de una manera abierta (también podríamos llamarla abstracta), pero posteriormente, se le ha ido dando forma para que encaje perfectamente en el mundo Web, usando las tecnologías existentes (URI, HTTP y XML). Como se verá posteriormente, hacer uso de estas tecnologías, puede significar renunciar a parte de su esencia.

REST es un estilo de arquitectura, por lo tanto, es conveniente explicar este concepto:

Un estilo de arquitectura es un conjunto coordinado de restricciones que controlan el funcionamiento y las características de los elementos de la arquitectura y permiten las relaciones de unos elementos con otros.

Los elementos de una arquitectura son tres: componentes, conectores y datos:

Componente: Es una unidad abstracta de instrucciones software y estados internos que proporciona una transformación de los datos a través de su interfaz.

Conector: Es un mecanismo abstracto que hace posible la comunicación, coordinación y cooperación entre componentes.

Dato: Es un elemento de información que se transfiere desde o hacia un componente a través de un conector

Figura 8: Elementos arquitectura

Durante el desarrollo del capítulo se irá definiendo REST como un estilo de arquitectura, es decir, se estudiarán:

Las restricciones que propone.

Los elementos (datos, conectores y componentes).

Las relaciones entre los elementos.

Una vez definido REST, se estudiará la manera de adaptarlo a las tecnologías Web actuales; HTTP, URI y XML. Para finalizar el capítulo, se verán los cabos sueltos que según algunos autores, deja REST en su definición.

5.2 Origen de REST, Roy Thomas Fielding

Roy Thomas Fielding es toda una autoridad en el mundo de la arquitectura de redes de ordenadores. Nació en Laguna Beach, California (Estados Unidos), y recibió un doctorado de la Universidad de California, Irvine en el año 2000.

Fielding ha estado muy involucrado en el desarrollo de las especificaciones HTTP, HTML y URI. Fue cofundador del proyecto Apache HTTP Server, y es miembro de la comunidad OpenSolaris. Actualmente trabaja como jefe científico en Irving, California.

Su disertación, Architectural Styles and the Design of Network-based Software Architectures (año 2000), describe REST como un principio clave en el mundo Web. Desde el primer momento, captó la atención del público. Parte de esta atención es debida a que la disertación contaba con el apoyo de Tim Berners-Lee.

En este capítulo se va a exponer la parte más importante de la disertación de Fielding. Este documento es la primera referencia a REST que existe. Como ya se ha comentado, Fielding fue el que acuñó el término e inventó el estilo de arquitectura REST.

5.3 Objetivos

Cuando Roy T. Fielding creó REST su disertación, perseguía unos objetivos muy concretos que Paul Prescod resumió en un artículo [13]:

Escalabilidad de los componentes de interacción. Generalidad de las interfaces. Independencia en el desarrollo de componentes. Sistemas intermedios para reducir el tiempo de interacción, mejorar la seguridad,

y encapsular los sistemas de herencia.

5.4 Restricciones de REST

Para poder conseguir los objetivos que se han comentado en el apartado anterior, REST define un conjunto de restricciones o características que deben cumplir las arquitecturas de Servicios Web:

1. Cliente Servidor

2. Sin estado

3. Caché

4. Sistema de capas

5. Interfaz Uniforme

6. Sistema de capas

7. Código bajo demanda

A continuación se va a explicar en qué consiste cada restricción.

5.4.1 Cliente-Servidor

La primera restricción que tiene REST está en común con el estilo Cliente-Servidor.

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.

De esta manera se ayuda a mejorar la portabilidad de la interfaz de usuario a través de múltiples plataformas. Además también se mejora la escalabilidad porque se simplifican las componentes del servidor al no tener que implementar las funcionalidades que van asociadas a la interfaz del usuario. Otro factor importante es que la separación permite a los componentes desarrollarse independientemente.

Figura 9: Cliente-Servidor

5.4.2 Sin estado (Stateless)

La segunda restricción está en común con el estilo client-stateless-server.

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 integramente en el cliente.

Figura 10: Stateless

Esta restricción mejora la visibilidad, eficiencia y escalabilidad. La visibilidad mejora porque el servidor no tiene que ocuparse de mirar en otros sitios ni realizar más operaciones para comprender la naturaleza de una simple petición. La eficiencia aumenta porque se hace más fácil recuperarse de errores parciales. La escalabilidad se ve también afectada porque al no hacer falta almacenar los estados entre las peticiones, los componentes pueden liberar recursos más rápidamente. Existe una simplificación de la implementación de aplicaciones al no existir gestión de recursos entre las peticiones.

La desventaja de esta restricción es que 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. Además poniendo el estado de la aplicación en el lado del cliente, se reduce el control para obtener un comportamiento consistente en la aplicación. La aplicación se hace muy dependiente de una correcta implementación de la semántica en las distintas versiones del cliente.

5.4.3 Caché

Esta tercera restricción la comparte REST con el estilo Client-Cachestateless-

Server Style.

Las respuestas a una petición deben poder ser etiquetadas como cacheable o no-cacheable. Si una respuesta es cacheable, entonces al cliente cache se le da permiso para reutilizar la respuesta más tarde si se hace una petición equivalente.

Figura 11: Caché

La ventaja de añadir esta restricción es que se evitarán determinadas peticiones al servidor, mejorando así la eficiencia y escalabilidad. 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.

5.4.4 Interfaz uniforme

Las siguientes restricciones que se van a comentar a partir de ahora son realmente las novedades que pretende aportar REST a las nuevas arquitecturas Web.

La principal característica que distingue a REST del resto de estilos de arquitecturas de red es el énfasis de usar una interfaz uniforme entre los componentes. Aplicando los principios de generalidad de la ingeniera del software a los componentes de la interfaz, se simplifica la arquitectura del sistema global y la visibilidad de interacciones se mejora. Las implementaciones se separan de los servicios que proporcionan, lo que anima al desarrollo independiente.

La desventaja de usar una interfaz uniforme es que degrada la eficiencia porque la información transferida está en una forma estandarizada y no según las necesidades que tenga la aplicación. El interfaz de REST está diseñado para ser eficiente con transferencias de datos de hipermedios (suelen ser datos voluminosos). Con esta decisión, está optimizado para la mayor parte de la Web pero no siendo así para otras

formas de arquitectura de interacción. Para obtener una interfaz uniforme, REST define cuatro restricciones de interfaz:

Identificación de recursos Manipulación de recursos a través de sus representaciones Mensajes auto-descriptivos Hipermedios como el motor del estado de la aplicación.

5.4.5 Sistema de capas

Para poder mejorar el comportamiento de la escalabilidad en Internet, se añade la restricción del sistema de capas. Este sistema permite tener una arquitectura compuesta por capas jerárquicas, limitando el comportamiento de los componentes porque no pueden “ver” mas allá de la capa con la que está interactuando.

Usando el sistema de capas se pueden simplificar los componentes moviendo las funcionalidades de uso infrecuente hacia sistemas intermedios compartidos. Estos sistemas pueden usarse para mejorar la escalabilidad permitiendo un balanceo de la carga de los servicios a través de múltiples redes y procesadores.

Figura 12: Sistema de capas

La principal desventaja de los sistemas de capas es que añaden cabeceras y retrasos al procesamiento de datos. Para un sistema de red que soporta la restricción de caché, este efecto puede verse reducido por los beneficios de usar un caché compartido en los sistemas intermedios. Colocando caches compartidos en los límites de un dominio organizativo, puede conseguirse una mejora significativa. Las capas además permiten directivas de seguridad para los datos que cruzan los límites organizativos, algo que necesitan los firewalls.

La combinación de interfaz uniforme y sistema de capas tiene unas características arquitectónicas similares a las del estilo pipe-and-filter. Aunque la interacción de REST es en dos sentidos, los flujos de datos de gran volumen de la interacción de los hipermedios, pueden ser procesados como flujos de datos de red. Usando REST, los sistemas intermedios pueden transformar el contexto de los mensajes porque estos son auto-descriptivos, su semántica es visible.

5.4.6 Código bajo demanda

La última restricción es opcional, consiste en permitir a los clientes tener la funcionalidad de descargar y ejecutar código en forma de applets y scripts. Esto simplifica el lado del cliente porque reduce el número de funcionalidades que tiene que tener implementadas al crearse. Las funcionalidades se pueden descargar posteriormente aumentando así la extensibilidad del sistema.

La principal desventaja de esta restricción es que reduce la visibilidad y puede influir en la seguridad del sistema. Sin embargo, tiene un propósito en el diseño arquitectónico de un sistema que abarque límites de organización múltiples. Con esta restricción, la arquitectura gana solamente una ventaja y sufre el resto de desventajas, por ello al ser una restricción opcional, en los contextos en los que el código bajo demanda no sea útil ni necesario, lo mejor será no incluirlo porque puede acarrear más problemas que beneficios.

5.5 Elementos arquitectónicos de REST

Hasta ahora se han visto las restricciones que usa REST para controlar el funcionamiento y las relaciones entre los distintos elementos (componentes, conectores y datos). Ahora se va a ver como concibió R. T. Fielding cada uno de estos elementos para que encajasen dentro de REST.

5.5.1 Datos en REST

A diferencia de los estilos basados en objetos distribuidos, donde todos los datos se encapsulan y son ocultados por los componentes del proceso, la naturaleza y el estado de los datos son un aspecto clave para REST. La forma racional de diseñar los datos puede verse en la naturaleza de los hipermedios distribuidos. Cuando se selecciona un link, la información debe trasladarse desde la localización donde está almacenado hasta donde será usado (la mayor parte de las veces por un humano). Esto va en contra de otros procesos distribuidos donde es posible, y a veces más eficiente, mover el “proceso agente” (procedimiento almacenado, expresión de búsqueda, etc) hasta los datos en vez de mover los datos hasta el proceso.

Un arquitecto de hipermedios distribuidos solo tiene tres opciones:

1) Renderizar los datos desde donde están localizados y enviar una imagen de formato fijo al receptor.

2) Encapsular los datos con una herramienta de renderización y enviar ambas cosas al receptor.

3) Enviar los datos en bruto al receptor junto con el metadato que describe el tipo de datos, para que el receptor pueda elegir su propia herramienta de renderización.

Cada opción tiene sus propias ventajas y desventajas:

OPCIÓN 1 OPCIÓN 2 OPCIÓN 3

VENTAJAS

Permite que toda la información sobre la verdadera naturaleza de los datos siga oculta dentro del remitente.

Hace que la implementación del cliente sea más sencilla.

Posee una gran flexibilidad

Permite al emisor permanecer simple y escalable, mientras que minimiza el volumen de datos transferidos

INCONVENIENTES

Restringe la funcionalidad del receptor y sitúa la mayor parte de la carga de procesamiento en el servidor, recayendo en problemas de escalabilidad.

Limita la funcionalidad del receptor y puede incrementar en gran manera el volumen de datos transferidos.

Pierde las ventajas de poder ocultar la información y requiere que el emisor y receptor entiendan los mismos tipos de datos.

Tabla 3 Tipos de diseño de datos

REST propone un híbrido de los tres puntos de vista centrándose en comprender los tipos de datos según los metadatos, pero limitándose a lo que es relevante para un interfaz estandarizado. Los componentes de REST se comunican trasfiriendo representaciones de un recurso en un formato que se ajusta a un conjunto de tipos de datos estándares. Estos tipos serán seleccionados dinámicamente basándose en las capacidades o deseos del receptor y en la naturaleza del recurso. Si la representación está en el mismo formato que el recurso en bruto, o si difiere, es algo que permanece oculto detrás de la interfaz. Los beneficios de la opción 2 son poder enviar una representación que consiste en instrucciones en el formato de datos estándar de la herramienta de datos encapsulada. REST gana en la separación de las funcionalidades del estilo cliente-servidor, pero permitiendo ocultar la información a través de un interfaz genérico que permite encapsular, evolucionar los servicios y proporciona un juego de funcionalidades amplio que podrá ser descargado.

5.5.1.1 Recursos e identificadores de recursos

La clave de la abstracción de la información en REST es el recurso. Cualquier información que pueda ser nombrada, puede ser un recurso, por ejemplo un documento, una imagen, un servicio temporal, una colección de otros recursos… En otras palabras, cualquier concepto que pueda ser llamado mediante una referencia en hipertexto, encaja en la definición de recurso. La definición exacta es, un recurso R es un miembro de la función MR(t), donde un tiempo t mapea un conjunto de entidades o valores que son equivalentes. Los valores del conjunto deben ser representaciones del recurso o identificadores del recurso.

Cuando un usuario desea realizar una actividad remota, no accederá a un Servicio directamente, sino que accederá a un recurso.

Figura 13: Funcionamiento REST

En el ejemplo de la Figura [14], un usuario quiere conocer remotamente al 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 un 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.

Algunos recursos son estáticos en el sentido de que cuando son examinados, se corresponden con el mismo conjunto de valores independientemente del tiempo. Otros varían en el tiempo.

Los recursos proporcionan generalidad abarcando muchas fuentes de información sin tener que distinguir artificialmente el tipo o la implementación. Además permiten unir la referencia a una representación porque puede negociarse el contenido al hacer una petición. Finalmente un autor puede referenciar un concepto en vez de a una representación en particular del concepto. De esta manera se elimina la necesidad de cambiar todos los links existentes siempre que la representación cambie (suponiendo que el autor use el identificador correcto).

REST usa un identificador de recurso para identificar un recurso en particular involucrado en una interacción entre componentes. Los conectores de REST proporcionan una interfaz genérica para acceder y manipular los valores de un conjunto de recursos independientemente del software que maneja la petición. La autoridad que asigna los identificadores de recursos, haciendo posible la referencia al recurso, es la responsable de validar la consistencia de la semántica al mapear a lo largo del tiempo.

Los sistemas tradicionales de hipertexto, que normalmente operan en un entorno local o cerrado, usan nodos únicos o identificadores de documento que cambian cada vez que la información cambia, confiando en que los servidores de liks mantengan las referencias separadas del contenido. Como los sistemas de link centralizados no son compatibles con la escalabilidad y los dominios multi-organizativos de la Web, REST apuesta porque sea el autor el que elija el identificador del recurso que mejor se ajuste a la naturaleza del concepto que será identificado. Naturalmente, la calidad del identificador es proporcional a la cantidad de dinero invertida para mantener la validez mientras que la información se mueve o desaparece a lo largo del tiempo.

5.5.1.2 Representación

Los componentes de REST realizan acciones en un recurso usando una representación que capture el estado actual o previsto de un recurso y transfiriendo la representación entre los componentes. Una representación es una secuencia de bytes más un metadato de representación que describe esos bytes. Otros nombres más comunes pero menos precisos para una representación incluye los casos: documento, archivo, y entidad de mensaje HTTP.

Lo que un cliente puede solicitar a un Servidor no es un recurso, es la representación o la modificación de un recurso. Un recurso es un término abstracto que define a la información a la que desea acceder el cliente, pero la representación es la información tangible que le llega. Por ejemplo, si desde un navegador Web se solicita ver el contenido de una página (recurso,abstracto), se estará solicitando una representación de un recurso, que en este caso será un documento HTML (representación, concreta). Una imagen que esté incluida en ese documento HTML, es la representación de otro recurso diferente. Si se desea modificar algo remotamente, se estará modificando un recurso.

Figura 14: Representación de recurso

Una representación consiste en datos, metadatos que describen los datos y en ocasiones, metadatos que describen a los metadatos (normalmente con propósito de verificar la integridad de un mensaje). Los metadatos suelen venir como parejas nombre-valor, donde el nombre corresponde a un estándar que define la estructura del valor y la semántica. Los mensajes de respuesta pueden incluir metadatos de representación y metadatos de recurso (información sobre el recurso que no es específico a la representación provista).

El control de datos define el propósito de los mensajes entre componentes, como pueden ser la acción solicitada o el significado de una respuesta. También se usa para parametrizar peticiones e invalidar el comportamiento que se tiene por defecto al conectar varios elementos. Por ejemplo, se puede modificar el comportamiento del caché controlando los datos del mensaje de petición o el de respuesta.

Dependiendo del control de datos del mensaje, una representación puede indicar el estado actual del recurso solicitado, el estado deseado o el valor de otro recurso cualquiera. Algunos casos concretos pueden ser la representación de los datos de entrada dentro de la petición de un cliente o la representación de las condiciones de error de una respuesta. Por ejemplo, para añadir un recurso desde una localización remota, es necesario que el autor envíe una representación al servidor, así se podrán establecer los valores del recurso para posteriores peticiones. Si el conjunto de valores de un recurso en un momento dado, consiste en múltiples representaciones, el proceso de negociación del contenido puede ser usado para elegir la mejor representación.

El formato de los datos de una representación es conocido como tipo de medio (media type). Una representación puede ser incluida en un mensaje y procesada por el receptor de acuerdo con el control de datos del mensaje y la naturaleza del tipo de medio. Algunos tipos de medios están previstos para procesos automatizados, otros para ser renderizados para que los usuarios los vean y otros son capaces de englobar a estos dos. Los tipos de medios compuestos se pueden utilizar para incluir representaciones múltiples en un solo mensaje.

El diseño de un tipo de medio puede afectar directamente a la percepción que tiene un usuario de los sistemas de hipermedios distribuidos. Cualquier dato que deba ser recibido antes de que el receptor pueda empezar a renderizar la representación, añade retraso a la interacción. Un formato de datos que contiene la parte más importante de la información de renderización al principio del mensaje, puede ser renderizado mientras el resto de la información está siendo recibida. Esto mejora notablemente la percepción del usuario al contrario que si tuviésemos que recibir todo el mensaje para empezar a renderizar.

Por ejemplo, un navegador Web que pueda renderizar un gran documento HTML mientras está siendo recibido, produce que el usuario tenga una mejor percepción del funcionamiento que si tuviese que esperar a recibir completamente el documento para ver algo en el navegador. Esto ocurre aunque el comportamiento de la red en los dos casos sea el mismo. Hay que darse cuenta de que la habilidad de renderizar y la capacidad de representación también pueden verse afectada por la elección del contenido. Si las dimensiones de tablas con tamaño dinámico y los objetos que

transportan deben ser determinadas antes de que puedan ser renderizadas, se sufrirá un retraso a la hora de ver una página de hipermedios.

Para terminar este apartado sobre los datos en REST se incluye la Tabla [3] que es un resumen de los datos usados por REST.

ELEMENTO DATO EJEMPLO DE LA WEB

Recurso El objetivo conceptual de una referencia de hipertexto

Identificador de recurso URIRepresentación Documento HTML, imagen JPEGMetadato de representación Tipo de medioRecurso metadato Source linkDatos de control Cache-Control

Tabla 4 Elementos de Datos REST

5.5.2 Conectores en REST

REST usa varios tipos de conectores para encapsular las actividades de acceso a recursos y transferir las representaciones de los recursos, como son los conectores Cliente, Servidor, Caché, Resolver y Túnel.

Los conectores presentan un interfaz abstracto para los componentes de comunicación, realzando la simplicidad que proporciona una separación de las competencias y ocultando las implementaciones subyacentes de los recursos y mecanismos de comunicación. La generalidad de la interfaz permite la sustitución: si los usuarios solo acceden al sistema a través de un interfaz abstracto, la implementación puede ser reemplazada sin que el usuario se de cuenta de ello. Como un conector gestiona la comunicación de red de los componentes, la información puede ser compartida por múltiples interacciones para potenciar la eficiencia.

Todas las interacciones de REST son sin estado (stateless). Cada petición contiene toda la información necesaria que necesita un conector para poder comprenderla, independientemente de las peticiones que hayan sido procesadas con anterioridad. Esta restricción conlleva cuatro funciones:

1. Elimina cualquier necesidad por parte de los conectores de retener el estado de la aplicación entre dos peticiones, reduciendo el consumo de recursos físicos y mejorando la escalabilidad.

2. Permite que las interacciones sean procesadas en paralelo sin que por ello requieran que el mecanismo de procesamiento comprenda la semántica de la interacción.

3. Permite a un sistema intermedio ver y comprender una petición de forma aislada, que es algo que puede ser necesario cuando los servicios cambian dinámicamente.

4. Fuerza a que esté presente en cada petición toda la información que influya para determinar si se puede usar una respuesta cacheable.

La interfaz del conector es similar a una invocación a proceso, pero con diferencias en el paso de parámetros y resultados.

Los parámetros de entrada consisten en la petición del control de datos, de un identificador de recurso que indica el objetivo de la petición y una representación opcional.

Los parámetros de salida consisten en responder con el control de los datos, un metadato de recurso opcional y una representación opcional.

Desde un punto de vista abstracto, la invocación es síncrona, pero los parámetros de entrada y de salida pueden ser pasados como flujos (streams) de datos. En otras palabras, el procesamiento puede ser invocado antes de que el valor de los parámetros se conozca totalmente. Así se evita el retardo de las grandes transferencias de datos del procesamiento por lotes.

Los principales tipos de conectores son Cliente, Servidor y Caché (los conectores Resolver y Túnel pasan a un segundo plano):

Conector Cliente: Es el que inicia la comunicación realizando una petición.

Conector Servidor: Es el que está escuchando las conexiones y responde a las peticiones para proporcionar acceso a sus servicios. Un componente puede incluir conectores de cliente y de servidor.

Conector Caché: Puede estar alojado en la interfaz de un conector cliente o servidor para salvar las respuestas cacheables de las interacciones en curso para usarlas en interacciones posteriores. Un caché puede ser usado por un cliente para evitar la repetición de la comunicación de red, o por un servidor para evitar repetir el proceso de generación de una respuesta. En ambos casos sirve para reducir retraso de la interacción. Un caché se implementa normalmente dentro del espacio de direcciones del conector que lo usa.

Figura 15: Mecanismo caché

Como puede verse en la Figura [16], el cliente solicita al servidor el recurso A. Si este recurso está definido como cacheable, el servidor caché almacenará la representación del recurso que se entrega. La siguiente vez que se solicite el recurso A, la petición no llegará más allá del servidor caché. Si la respuesta hubiese sido etiquetada como no-cacheable la petición habría sido redirigida de nuevo hasta el servidor.

Algunos conectores de caché son compartidos, esto significa que una respuesta puede ser usada para responder a otro cliente distinto del que originó la respuesta almacenada en el caché. Compartir caché es efectivo reduciendo el impacto en aquellos servidores populares a los que los clientes acceden para obtener la misma información. Es particularmente efectivo cuando el caché se prepara jerárquicamente para cubrir a grandes grupos de usuarios, como es el caso de la Intranet de una compañía, los clientes de un proveedor de servicios de Internet o las Universidades. Sin embargo, el caché compartido también puede conllevar errores si una respuesta no es la misma consultando el caché que realizando una nueva petición.

REST pretende equilibrar la transparencia en el comportamiento del caché con el uso eficiente de la red, antes de asumir que la transparencia absoluta es siempre necesaria.

El caché puede determinar si una respuesta es cacheable porque la interfaz es genérica y no específica para cada recurso. Por defecto, una respuesta a una petición repetida, es cacheable y la respuesta a otra petición no lo es. Si de alguna manera la autenticación del usuario forma parte de la petición o si la respuesta indica que no puede ser compartida, entonces la respuesta sólo será cacheable para un caché no-compartido. Un componente puede modificar este comportamiento incluyendo el control de datos que puede marcar una interacción como cacheable, no-cacheable, o cacheable por un periodo de tiempo.

Un Conector Resolver traduce parcial o completamente el identificador de un recurso en una dirección de red, esto es necesario para establecer conexiones entre componentes. Por ejemplo, la mayoría de las URI incluyen un servidor de nombres DNS como mecanismo para identificar el recurso. Para iniciar una petición, un navegador Web conseguirá el hostname de la URI y usará un resolver DNS para obtener

la dirección de protocolo de Internet. Otro ejemplo es que algunos esquemas de identificación necesitan un sistema intermedio para traducir un identificador permanente en una dirección más transitoria para acceder al identificador de recurso.

Un último tipo de conector es el Conector Túnel, que simplemente permite la comunicación a través de los límites de la conexión, como pueden ser firewalls o puertas de acceso de bajo nivel. La única razón por la cual se modela como una parte de REST y no como algo abstracto que forma parte de la red, es que algunos componentes de REST pueden cambiar dinámicamente de tener un comportamiento dinámico a comportarse como un túnel. El principal ejemplo es un proxy HTTP que cambia a ser un túnel en respuesta a una petición del método CONNECT, permitiendo así al cliente comunicarse directamente con un servidor remoto usando un protocolo diferente como TLS (los proxies no permiten su uso). El túnel desaparece cuando los extremos terminan la comunicación.

Para terminar este apartado sobre los conectores en REST se incluye la Tabla [4] que es un resumen de los conectores usados por REST.

CONECTOR EJEMPLO DE LA WEB

Cliente libwww, libwww-perlServidor Libwww, Apache API, NSAPICache Cache del navegadorResolver Bind (DNS lookup library)Túnel SOCKS, SSL tras HTTP CONNECT

Tabla 5 Conectores REST

5.5.3 Componentes en REST

Los componentes que tiene REST son: Agente Usuario, Servidor, Gateway (puerta de acceso) y Proxy.

Un Agente Usuario usa un conector cliente para iniciar una petición y ser el verdadero receptor de la respuesta. El ejemplo más común es el navegador Web, proporciona acceso a los servicios de información y renderiza las respuestas del servicio de acuerdo con las necesidades de la aplicación.

El Servidor usa un conector de servidor para gobernar el espacio de nombres cuando se le solicita un recurso. Es el que realiza la representación de sus recursos y debe ser el receptor último de todas las peticiones que soliciten modificar los valores de sus recursos. Cada servidor proporciona una interfaz genérica para sus servicios como una jerarquía de recursos. Los detalles de implementación de los recursos se ocultan detrás de la interfaz.

Los componentes de los sistemas intermedios actúan a la vez como cliente y como servidor para llevar a sus destinos las posibles transacciones, peticiones y respuestas. Un componente Proxy es un sistema intermedio seleccionado por el cliente para proporcionar la encapsulación de la interfaz de otros servicios, transporte de datos, perfeccionamiento del funcionamiento o seguridad. Los componentes de un Gateway son un sistema intermedio impuesto por la red o el servidor para proporcionar una encapsulación del interfaz de otros servicios, transmisión de datos, perfeccionamiento del funcionamiento o seguridad. La diferencia entre proxy y puerta de acceso es que el cliente es el que determina cuando va a usar un proxy.

A continuación se muestra la Tabla [5] que es una gráfica resumen de los componentes REST:

COMPONENTE EJEMPLO DE LA WEB

Servidor Origen Apache httpd, Microsoft IISGateway Squid, CGI, Reserve ProxyProxy CERN Proxy, Netscape Proxy, GauntletUsuario Agente Netscape Navigator, Linxs, MOMspider

Tabla 6 Componentes REST

5.6 Vistas de la arquitectura REST

Ahora que se han analizado los elementos de REST por separado, puede hacerse uso de las vistas de la arquitectura para describir las relaciones que existen entre los elementos, es decir, observar como trabajan los elementos de manera conjunta. Se usarán tres tipos de vista: Procesos, Conectores y Datos.

5.6.1 Vista de proceso

La vista de proceso de una arquitectura es principalmente efectiva para analizar las relaciones entre los componentes desde el punto de vista del camino que siguen los datos a través del sistema. Desafortunadamente la interacción de un sistema real normalmente involucra un gran número de componentes por lo que puede resultar un tanto caótico.

La siguiente Figura [17], va a resultar útil para observar el camino que siguen las peticiones desde que el cliente las realiza. Se muestra un ejemplo de vista de proceso de una arquitectura basada en REST para un instante determinado durante el procesamiento de tres peticiones en independientes en paralelo.

Figura 16: Vista proceso

Se pueden observar tres interacciones diferentas: a, b y c. Cada una representa una petición que realiza el cliente para conseguir un recurso en un servidor remoto diferente. Las interacciones no fueron completadas por el conector de caché que se encuentra en el lado del cliente, por tanto, las peticiones han tenido que ser redirigidas al servidor remoto de acuerdo con el identificador de recurso y la configuración del conector cliente.

La petición a) ha sido redirigida a un proxy local que accede a una puerta de acceso que ha encontrado con una búsqueda al DNS, posteriormente manda la petición a un servidor cuyos recursos están definidos usando una arquitectura de petición de objetos encapsulados.

La petición b) se envía directamente a un servidor que puede llevarla a cabo usando su propio caché. Como ya se comentó anteriormente el caché de cliente falló al intentar este proceso, pero el servidor posee otro caché propio que si ha podido responder.

La petición c) se envía a un proxy que puede usar el acceso WAIS, un servicio de información separado de la arquitectura Web, que traduce la respuesta WAIS a un formato reconocido por el interfaz de conector genérico. Cada componente sólo se entera de la interacción con el conector de su propio cliente o del servidor.

La separación de las tareas de las que se preocupan el cliente y el servidor simplifica la implementación de los componentes, reduce la complejidad de la semántica del conector, aumenta la efectividad del funcionamiento y mejora la escalabilidad de los componentes del servidor. La restricción del sistema de capas permite a los sistemas intermedios (proxies, puertas de acceso y firewalls) introducirse en varios puntos de la comunicación sin tener que cambiar los interfaces entre los componentes, permitiendo así ayudar a la comunicación y mejorar el funcionamiento de cara a la escalabilidad.

REST permite los sistemas intermedios obligando a que los mensajes sean auto-descriptivos (la interacción es sin estado entre las peticiones). Los métodos estándar y los tipos de medio se usan para indicar la semántica y el intercambio de información y las respuestas indican si son cacheables o no de una manera explícita.

Cuando los componentes se conectan dinámicamente, su disposición y función ante acciones de una aplicación determinada tiene características similares al estilo pipe-and-filter. Aunque los componentes de REST se comunican de manera bidireccional, el procesamiento de cada dirección es independiente. El interfaz de conector genérico permite a los componentes tomar parte en las propiedades de cada petición o respuesta.

Los servicios pueden ser implementados usando una compleja jerarquía de sistemas intermedios y servidores distribuidos. La naturaleza stateless de REST permite a cada interacción ser independiente de las demás, eliminando la necesidad de que toda la topología de componentes se entere de todo, que es una tarea imposible para una arquitectura basada en Internet. Además permite a los componentes actuar como destinos o sistemas intermedios, determinándolo dinámicamente según el objetivo de cada petición. Los conectores solo necesitan conocer la existencia de otros conectores durante la comunicación, aunque pueden conocer la existencia y capacidades de otros componentes por razones de funcionamiento.

5.6.2 Vista de conector

La vista de conector de una arquitectura se centra en los mecanismos de comunicación entre componentes. Para una arquitectura basada en REST, son particularmente interesantes las restricciones que definen la interfaz genérica.

Figura 17: Vista conector

El conector del cliente examina el identificador de recurso para seleccionar el mecanismo de comunicación apropiado para cada petición. Por ejemplo, un cliente puede configurarse para conectarse a un componente proxy específico, o para que rechace las peticiones a un determinado subconjunto de identificadores.

REST no restringe la comunicación para que use un protocolo en particular, pero restringe el interfaz entre los componentes, y por lo tanto el alcance de la interacción

y de la implementación. Por ejemplo, el principal protocolo de transporte es HTTP, pero la arquitectura también incluye acceso a recursos que hay en los servidores de red como puede ser FTP, Gopher y WAIS. La interacción con esos servicios está restringida a la semántica de los conectores de REST. Esta restricción sacrifica algunas de las ventajas de otras arquitecturas como por ejemplo la interacción con estado que usa WAIS, para obtener las ventajas de una interfaz simple y genérica de semántica de conectores. Las interfaces genéricas hacen posible acceder a muchos servicios a través de un simple proxy. Si una aplicación necesita las capacidades de otra arquitectura, puede implementarlas e invocarlas como si fuera un sistema separado corriendo en paralelo, es un caso parecido a como la arquitectura Web tiene un interfaz con los recursos “telnet” y “mailto”.

5.6.3 Vista de datos

La vista de datos de una arquitectura nos revela el estado de la aplicación como un flujo de información a través de los componentes.

REST está concebido para los sistemas de información distribuidos, ve una aplicación como una estructura cohesiva de información y alternativas de control a través de la que un usuario puede realizar una tarea. Por ejemplo, buscar una palabra en un diccionario on-line es una aplicación, igual que realizar una visita a un museo virtual o estudiar unos apuntes para un examen. Cada aplicación define sus objetivos para los sistemas subyacentes.

La interacción de los componentes ocurre en forma de mensajes de tamaño dinámico. Los mensajes pequeños o medianos se usan para el control de la semántica, pero la mayor parte de la aplicación trabaja con grandes mensajes que contienen una representación completa del recurso. La forma más frecuente de semántica para peticiones es solicitar la representación de un recurso, (como por ejemplo el método “GET” de HTTP), que puede ser almacenado en caché para un uso posterior.

REST concentra todo el control de estado en la representación recibida como respuesta a las interacciones. El objetivo es mejorar la escalabilidad del servidor eliminando cualquier necesidad de tener al servidor enterado del estado del cliente, sólo debe saber de la petición actual. El estado de una aplicación está por lo tanto definido por sus peticiones pendientes, la topología de los componentes conectados, las peticiones activas en esos conectores, el flujo de datos de representación en respuesta a esas peticiones y el procesamiento de las representaciones cuando son recibidas por el agente usuario.

Una aplicación alcanza un estado estacionario siempre que no tenga peticiones pendientes, por ejemplo si no tiene peticiones pendientes y todas las respuestas al conjunto de peticiones realizadas han sido completamente recibidas o por lo menos hasta el punto de poder tratarse como flujo de datos de representación. Para una aplicación en el navegador, este estado se corresponde con una “página Web”, incluyendo la representación principal y las representaciones auxiliares, tales como imágenes, applets, y las hojas del estilo. La importancia de los estados estacionarios es

ver el impacto que tiene en la forma de percibir un usuario el funcionamiento y ver como afecta el tráfico a ráfagas a la red.

La percepción que tiene el usuario del funcionamiento de una aplicación en el navegador está determinada por el tiempo de retardo entre estados estacionarios; el periodo de tiempo que transcurre entre el instante en el que se selecciona un link de hipermedio de la página Web, y el instante en el que la información ha sido renderizada. La optimización del funcionamiento de un navegador está centrada en reducir este retardo de comunicación.

Figura 18: Tiempo de retardo

Como las arquitecturas basadas en REST se comunican transfiriendo representaciones de recursos, el tiempo de retardo puede mejorar mediante el diseño de los protocolos de comunicación y el diseño de los formatos de representación de los datos. La capacidad de renderizar una respuesta a la vez que está siendo recibida está determinada por el diseño de los tipos de medios.

Una observación interesante es que la petición más eficiente de la red es la que no utiliza la red. Es decir, la capacidad de reutilizar una respuesta cacheable da lugar a una mejora considerable del funcionamiento de la aplicación. Aunque el uso del caché añade retardo a cada petición individual debido a las operaciones de búsqueda, el retardo medio de la petición se reduce significativamente cuando incluso es solo un pequeño porcentaje de peticiones el que consigue obtener una respuesta del caché.

El siguiente punto de control de una aplicación reside en la representación del primer recurso solicitado, obtener esa representación es una prioridad. Por tanto, la interacción de REST se mejora con los protocolos que “primero responden y después piensan”. En otras palabras, un protocolo que requiere múltiples interacciones sobre cada acción del usuario y que da prioridad a cosas como negociar las capacidades, será desde el punto de vista perceptivo más lento que otro protocolo que envíe la respuesta que crea más conveniente y si se ha equivocado, proporcione al cliente una lista con las posibles alternativas.

El estado de la aplicación está controlado y almacenado por el usuario y puede estar compuesto por representaciones de múltiples servidores. Esto libera al servidor de los problemas de escalabilidad que supone almacenar el estado. Además permite al usuario manipular directamente el estado, anticiparse a los cambios y saltar de una aplicación a otra (por ejemplo mediante los libros de direcciones y los diálogos de entradas URI).

La aplicación modelo es por tanto un motor que se mueve de un estado al siguiente examinando y eligiendo entre las transiciones de estado alternativas. Se hace teniendo en cuenta el interfaz usuario del navegador de hipermedios. Sin embargo, el estilo no obliga a que todas las aplicaciones sean navegadores. De hecho, los detalles de la aplicación se ocultan desde el servidor mediante el conector de interfaz genérico y así un usuario podría ser un robot que realiza una recuperación de datos para un servicio de indexación, un agente que busca información según unos criterios o un programa de mantenimiento que comprueba que no haya enlaces de referencia rotos.

5.7 HTTP, URI y XML en REST

Desde 1994, REST ha sido usado para guiar y diseñar la arquitectura de la Web moderna. Ahora trataremos de describir la experiencia aprendida de aplicar REST a los estándares de Internet para HTTP, URI y XML. HTTP y URI son las especificaciones que definen un interfaz genérico usado por todos los componentes de interacción en la Web.

5.7.1 Estandarizando la Web

La motivación de desarrollar REST era crear un modelo de arquitectura que describiese como debería funcionar la Web, así como que pudiese servir como marco de trabajo para los estándares de protocolos Web. REST ha sido aplicado para describir la arquitectura Web deseada, ayudar identificando problemas existentes, comparar soluciones alternativas, y asegurarse de que el protocolo no viole las restricciones que hacen que la Web funcione correctamente. Este trabajo fue realizado por el Internet Engineering Taskforce (IETF) y el World Wide Web Consortium (W3C), gracias a sus esfuerzos por definir un estándar de arquitectura para la Web: HTTP, URI y HTML.

La primera edición de un estilo de arquitectura parecido a REST fue desarrollada entre Octubre de 1994 y Agosto de 1995, principalmente como un medio para comunicar los conceptos Web como se escribieron las especificaciones de HTTP/1.0 y los inicios de HTTP/1.1. Fue continuamente mejorado en los siguientes cinco años y se aplicó a varias revisiones y extensiones de los estándares de protocolos Web. A REST se le conoció originalmente por “HTTP Object Model”, un nombre que puede inducir a confusión. El nombre de “Representational State Transfer” intenta evocar la imagen de cómo se comporta una aplicación Web bien diseñada: una red de paginas Web (una máquina de estados virtual), dando como resultado la siguiente página (representando el siguiente estado de la aplicación) que se le transfiere al usuario para que lo renderice y use.

Figura 19: REST transición de estados

REST no esta concebido para capturar todas las posibilidades de uso de los estándares de protocolos Web. Hay aplicaciones de HTTP y URI que no encajan en el modelo de aplicación de un sistema de hipermedios distribuidos. Lo importante, sin embargo, es que REST captura todos los aspectos de los sistemas de hipermedios distribuidos que son considerados imprescindibles para el comportamiento y funcionamiento de la Web. Optimizar el comportamiento del modelo dará como resultado un comportamiento óptimo de la arquitectura Web desarrollada. En otras palabras, REST está optimizado para el caso común, de manera que las restricciones aplicadas a la arquitectura Web están optimizadas para ese caso.

5.7.2 REST aplicado a URI

Uniform Resource Identifiers (URI) son los elementos más simples de la arquitectura Web y a la vez los más importantes. URI ha sido conocido por muchos nombres: direcciones WWW, Universal Document Identifiers, Universal Resource Identifier, URL y URN. Dejando a un lado el nombre, la sintaxis URI ha permanecido relativamente sin cambios desde 1992. Sin embargo, la especificación de las direcciones Web también define el alcance y la semántica de lo que entendemos por recurso, el cual ha cambiado desde las primeras arquitecturas Web. REST define URI como identificador de recursos. También definió toda la semántica de la interfaz genérica para manipular los recursos a través de sus representaciones.

5.7.2.1 Redefinición de recurso

Las primeras arquitecturas Web definían URI como un identificador de documentos. Los identificadores se definían en los términos de localizaciones de documentos en la red. Los protocolos Web podían ser usados para recuperar esos documentos. Sin embargo, esta definición resultó ser insatisfactoria por varias razones:

El autor estaría identificando el contenido transferido, lo que implicaría que el identificador debería cambiar siempre que el contenido cambie.

Existen muchas direcciones que se corresponden con un servicio y no con un documento.

Existen direcciones que no se corresponden con un documento en algunas ocasiones, como sucede cuando un documento ya no existe o cuando la dirección se está usando solamente para nombrar y no para alojar información.

La definición de recurso en REST está basada en una simple premisa: los identificadores deberían cambiar lo menos posible porque la Web no usa servidores de links, los autores necesitan un identificador que encaje con la semántica que ellos conciben como una referencia a hipermedio, permitiendo a la referencia permanecer estática aunque el resultado de acceder a esa referencia cambie con el tiempo. REST logra esto definiendo un recurso como la semántica de lo que el autor piensa identificar mejor que definirlo como el valor correspondiente a esa semántica en el momento en el que se crea la semántica. Por tanto es tarea del autor asegurarse de que el identificador elegido para una referencia identifica la semántica.

5.7.2.2 Manipulación

Definir los recursos como una URI que identifica un concepto en vez de un documento, deja una pregunta: ¿Cómo se accede, manipula o transfiere un concepto para conseguir algo útil cuando seleccionamos un link de hipertexto? REST responde a esta pregunta definiendo las cosas que son manipuladas como representaciones del identificador de recurso, en vez del recurso en sí. Un servidor mantiene la relación entre el identificador de recurso y el conjunto de representaciones que le corresponden. Por tanto, un recurso se manipula transfiriendo representaciones a través de una interfaz genérica definida por el identificador de recurso.

Figura 20: Solicitud recurso

La información que se oculta es una de las claves de la ingeniería del software que motiva el interfaz uniforme de REST, porque un cliente esta restringido a manipular la representación de un recurso en vez de acceder directamente a su implementación. La implementación puede ser construida en la forma deseada por su autor sin que esto tenga ningún impacto en como los clientes usan la representación. Además si existen múltiples representaciones del recurso en el instante en el que se quiere acceder a él, un

algoritmo de selección de contenido puede ser usado dinámicamente para seleccionar el que mejor se adapte a las necesidades del cliente. La desventaja, por supuesto, es que un recurso no es tan directo como un archivo.

Las URI a las que se accede pueden ser físicas o lógicas. Visto de otra manera, los recursos a los que acceden los clientes pueden ser generados dinámicamente (URI lógica). Por ejemplo, si se accede a una aplicación que está conectada a una base de datos en el servidor, al realizar una consulta, se está solicitando una búsqueda en concreto, y no hace falta que el servidor tenga almacenadas todas las posibles combinaciones de las búsquedas como páginas estáticas, puede conectarse a la base de datos, y cuando obtenga el resultado generar dinámicamente la representación del recurso.

Figura 21: Representación recurso dinámico

Este mecanismo también puede ser útil para solicitar una representación de un recurso en un determinado formato. Por ejemplo, se puede solicitar que la información sea devuelta en formato XML, HTML… En este caso, el servidor debería acceder al recurso, generar la representación en el formato que se le indique y entregarla. La información tendrá diferentes URIs según su representación, por ejemplo: http://informacion_deseada.xml o http://informacion_deseada.html.

5.7.2.3 Acceso remoto

El reto del acceso remoto a través de un interfaz uniforme de la Web es debido a la separación entre la representación que puede ser recuperada por un cliente y el mecanismo que se usa en el servidor para almacenar, generar o recuperar el contenido de esa representación.

Para poder trabajar con un recurso existente, el autor primero tiene que obtener la URI del recurso fuente específico: el conjunto de URIs que emparejan el manejador subyacente con el recurso objetivo. No siempre un recurso se mapea como un fichero en concreto, pero todos los recursos que no son estáticos derivan de otros recursos. Un autor podría encontrar todos los recursos fuente que deben ser editados para modificar la representación de un recurso. Los mismos principios se aplican a cualquier forma derivada de representación, negociación de contenidos, scripts, servlets, configuraciones de mantenimiento…

El recurso no es el objeto almacenado. El recurso no es un mecanismo que usen los servidores para manejar el objeto almacenado. El recurso es un mapeo conceptual. El servidor recibe el identificador (que identifica el mapeo) y lo aplica a una implementación particular del mapeo para encontrar la implementación del manejador que le corresponde en ese momento. Posteriormente, la implementación del manejador selecciona la acción y respuesta apropiadas basándose en el contenido solicitado. Su naturaleza no se le puede revelar un cliente que tenga solamente acceso a través del interfaz Web.

Figura 22: Modificación Recurso

Por ejemplo, se va a considerar el caso de lo que ocurre cuando un sitio Web crece en cuanto al número de usuarios y decide reemplazar sus viejos servidores X basados en una plataforma XOS por servidores Apache corriendo en FreeBSD. El hardware de almacenamiento de disco se cambia. El sistema operativo también se cambia. El servidor HTTP también se cambia. Quizás hasta los métodos de generación de respuestas se cambian. Sin embargo, lo que no necesitamos cambiar es el interfaz Web: si se diseña correctamente, el espacio de nombres del nuevo servidor puede migrar desde el viejo, esto significa que desde la perspectiva del cliente que solo sabe de recursos y no de cómo están implementados, nada ha cambiado excepto la robustez del sitio.

5.7.2.4 Ligando la semántica al URI

Como se ha mencionado, un recurso puede tener muchos identificadores. En otras palabras, pueden existir dos o más URIs diferentes que tienen semántica equivalentes cuando se usan para acceder a un servidor. También es posible tener dos URIs que den como resultado el mismo mecanismo cuando se usan para acceder al servidor, y que sin embargo cada URI identifique un recurso diferente, porque no signifiquen lo mismo.

La semántica es un producto de asignar los identificadores de recursos y de dotar a los recursos con representaciones. En cualquier momento, el software del servidor o del

cliente necesita conocer o comprender el significado de una URI. Ellos actúan conducidos por la asociación que hizo el creador entre un recurso y la representación de la semántica identificada por el URI. En otras palabras, no hay recursos en el servidor, solamente hay mecanismos que proporcionan respuestas a través de un interfaz definido por los recursos. Puede parecer extraño pero es la esencia de lo que hace que la Web funcione con tantas y tan diferentes implementaciones.

Es competencia de todo ingeniero definir las cosas en términos de las características de los componentes que serán usados para obtener el producto terminado. La Web no funciona de esa manera. La arquitectura Web consiste en restricciones de los componentes del modelo de comunicación, basadas en el rol de cada componente durante una acción de la aplicación. Esto evita que los componentes tengan que asumir nada que vaya más allá de la abstracción de recurso, escondiendo así el mecanismo que se usa en cada lado del interfaz abstracto.

5.7.2.5 Problemas entre REST y URI

Como la mayoría de los sistemas del mundo real, no todos los componentes que se desarrollan de la arquitectura Web obedecen todas las restricciones presentes en este diseño de arquitectura. REST ha sido usado para definir mejoras en la arquitectura y para identificar errores. Los problemas ocurren cuando, debido a la ignorancia o descuido, una implementación de software se desarrolla violando las restricciones arquitectónicas. Mientras que los problemas no se puedan evitar en general, es posible identificarlos antes de que se estandaricen.

Aunque el diseño de URI encaja perfectamente con las características de los identificadores de REST, la sintaxis sola es insuficiente para forzar a los autores a definir sus propias URI de acuerdo al modelo de recurso. Una práctica errónea es incluir información que identifique al usuario dentro de la URI que referencia la representación de una respuesta de hipermedio porque eso significaría que el servidor controlaría el estado de la sesión almacenando las preferencias de los usuarios y cosas similares. Sin embargo, violando las restricciones de REST, esos sistemas producen que el caché compartido no sea efectivo, reduciendo la escalabilidad del servidor y dando como resultado efectos indeseables cuando los usuarios comparten referencias con otros.

Otro conflicto con el interfaz de recursos de REST ocurre cuando el software intenta tratar la Web como un sistema distribuido de ficheros. Puesto que los sistemas de ficheros exponen la implementación de su información, las herramientas existen para poder migrar esa información a través de múltiples sitios para hacer un balance de cargas y redistribuir el contenido a los usuarios. Sin embargo, pueden hacerlo sólo porque los ficheros tienen un conjunto de semántica fijo (una secuencia de bits conocidos) que pueden ser fácilmente duplicados. Por el contrario, tratar de migrar el contenido de un servidor Web como ficheros fallará porque la interfaz de recurso no siempre encaja con la semántica de sistema de ficheros, y porque los datos y metadatos están incluidos y dan sentido a la semántica de una representación. El contenido de un servidor Web puede ser copiado a sitios remotos, pero solo si se copia también el

mecanismo y la configuración del servidor, o copiando selectivamente solo los recursos cuyas representaciones se sabe que son estáticas.

5.7.3 REST aplicado a HTTP

HTTP tiene un papel especial en la arquitectura Web por ser el principal protocolo del nivel de aplicación para la comunicación entre componentes Web, y por ser el único protocolo diseñado específicamente para transferir representaciones de recursos. Al contrario que URI, se necesitaron muchos cambios para que HTTP soportase la nueva arquitectura Web.

Este apartado va a centrarse en tres características de HTTP:

Extensibilidad Mensajes Auto-descriptivos Métodos HTTP y su uso en REST

5.7.3.1 Extensibilidad

Una de las mayores metas de REST es soportar el despliegue gradual y fragmentado de cambios dentro de una arquitectura ya desarrollada. HTTP fue modificado para soportarlo mediante la introducción de requerimientos y reglas que extienden cada elemento de la sintaxis de protocolo.

5.7.3.1.1 Versiones del protocolo

HTTP es una familia de protocolos, distinguidos por un número mayor o menor que comparten el nombre principal porque corresponden al protocolo esperado cuando se comunican directamente con un servicio basado en el espacio de nombres URL. Un conector debe obedecer a las restricciones que indica la versión del elemento del protocolo HTTP incluida en cada mensaje.

La versión HTTP de un mensaje representa las capacidades del protocolo del remitente y la compatibilidad (el mayor número de versión) del mensaje que se envía. Esto permite a un cliente usar un subconjunto reducido (HTTP/1.0) de características a la hora de realizar una petición normal de HTTP/1.1, mientras que al mismo tiempo se le indica al receptor que soporta una comunicación completa en HTTP/1.0. En otras palabras, se permite una especie de negociación de la forma del protocolo. Cada conexión en la cadena de peticiones y respuestas puede operar con el mejor nivel de protocolo teniendo en cuenta la limitación de algunos clientes o servidores que tomen parte en la cadena.

La intención del protocolo es que el servidor debería siempre responder con la mayor versión del protocolo y que se entienda con la mayor versión del mensaje de petición

del cliente. La restricción es que el servidor no puede usar las características opcionales de su mayor versión del protocolo que no estén presentes en el cliente. No existen características exigidas de un protocolo que no puedan ser usadas entre versiones anteriores y posteriores porque sería un cambio incompatible. Las únicas características de HTTP que pueden depender de la versión del protocolo son las que se interpretan por sistemas adyacentes de la comunicación, porque HTTP no requiere que toda la cadena de componentes intermediarios en las peticiones y respuestas tenga la misma versión.

Figura 23: Versiones HTTP Cliente-Servidor

Esas reglas existen para ayudar al despliegue de múltiples revisiones de los protocolos y para prevenir que los arquitectos de HTTP olviden que el despliegue del protocolo es un aspecto importante del diseño. Lo realizan haciendo fácil la diferenciación entre cambios compatibles con el protocolo y cambios incompatibles. Los compatibles son fáciles de desplegar y la comunicación de las diferencias se puede alcanzar dentro del flujo del protocolo. Los cambios incompatibles son difíciles de desplegar porque necesitan asegurar que son aceptados antes de que el flujo del protocolo comience.

5.7.3.1.2 Elementos de protocolo extensibles

Desde los orígenes, HTTP no define un conjunto de reglas consistente para definir como deben desplegarse los cambios dentro del espacio de nombres. Éste era uno de los primeros problemas abordados por la especificación.

La semántica de la petición del HTTP está significada por el nombre del método de la petición. La extensión del método está permitida siempre que un conjunto de semánticas que se puedan estandarizar, pueda ser compartido entre cliente, servidor y cualquier sistema intermedio que haya entre ellos. Desafortunadamente, las primeras extensiones de HTTP, específicamente el método HEAD, hicieron que el análisis de una respuesta HTTP fuera dependiente del conocimiento de la semántica del método requerido. Esto condujo a una contradicción en el despliegue: si un receptor necesita conocer la semántica de un método antes de que pueda ser reenviado con seguridad a un

sistema intermedio, entonces todos los sistemas intermedios deben estar actualizados antes de que se pueda desplegar.

Estos problemas en el despliegue fueron solucionados separando las reglas de análisis y reenvío de mensajes HTTP de la semántica asociada con los nuevos elementos del protocolo HTTP. Por ejemplo, HEAD es el único método para el que la longitud del contenido en el campo de cabecera, tiene otro significado que decir la longitud del cuerpo del mensaje, y ningún nuevo método puede cambiar el cálculo de la longitud del mensaje.

Asimismo, HTTP necesita una regla general para interpretar los nuevos códigos de estado de la respuesta, de manera que las nuevas respuestas podrían ser desplegadas sin dañar a los viejos clientes. Por tanto se impone la regla de que cada código de estado pertenezca a una clase diferenciada por los tres primeros dígitos decimales:

RANGO DE CÓDIGOS SIGNIFICADO DEL MENSAJE

100-199 El mensaje contiene una respuesta de información provisional

200-299 La petición tuvo éxito

300-399 La petición necesita ser redirigida a otro recurso

400-499 El cliente cometió un error que no debe repetirse

500-599 El servidor encontró un error, pero que el cliente podrá obtener la respuesta más tarde (o a través de otro servidor)

Tabla 7 Significado mensajes HTTP Como la regla para los nombres de los métodos, ésta regla de extensibilidad introduce un requisito en la arquitectura actual, que es anticipar futuros cambios. Los cambios pueden ser desplegados en una arquitectura existente sin que haya reacciones adversas en los componentes.

5.7.3.1.3 Actualizaciones

Añadiendo en la cabecera, el campo de actualización para HTTP/1.1 se reduce la dificultad de desplegar cambios incompatibles, permitiendo al cliente avisar de que quiere usar un protocolo mejor mientras se comunica con un protocolo más antiguo. La actualización fue añadida específicamente para soportar la sustitución de HTTP/1.x con

los futuros protocolos que serán más eficientes con algunas tareas. Por tanto, HTTP no sólo soporta extensibilidad interna, sino que también soporta una sustitución completa durante una conexión activa. Si el servidor soporta un protocolo mejor y decide cambiar, solamente responde con un estado 101 y continúa como si la petición fuese recibida en ese protocolo mejorado.

5.7.3.2 Mensajes auto-descriptivos

REST tiene la restricción de que los mensajes entre componentes sean auto-descriptivos para soportar un procesamiento inmediato de las interacciones. En este apartado se estudiarán algunas características de los mensajes HTTP.

La identificación de un host dentro de la petición

Codificación de capas

Independencia semántica

Independencia del transporte

Límites de tamaño

Control de Caché

Negociación del contenido

5.7.3.2.1 Identificación de Host dentro de la petición

HTTP/1.0 y HTTP/1.1 incluyen la información de la URL del host de destino dentro del campo cabecera de un mensaje de petición. El despliegue de esta característica se hizo tan importante que la especificación HTTP/1.1 indica que se rechace cualquier petición que no contenga el campo host. Como resultado, existen muchos servidores ISP que contienen decenas de miles de sitios Web virtuales basados en el nombre, que comparten la misma dirección IP.

Figura 24: Mensaje HTTP, URL HOST

5.7.3.2.2 Codificación de capas

HTTP hereda su sintaxis de MIME. MIME no define tipos de medios basados en capas, prefiere colocar una etiqueta del tipo de medios exterior dentro del valor del campo del tipo de contenido. Sin embargo, esto impide a un receptor determinar la naturaleza de un mensaje codificado sin decodificar las capas. Una de las primeras extensiones de HTTP trabajaba sobre este fallo listando la codificación de las capas externas de forma separada dentro del campo de codificación de contenido, y colocando una etiqueta para los tipos de medios en el tipo de contenido. Esta fue una solución bastante mala porque cambiaba la semántica del tipo de contenido sin cambiar el nombre del campo, como resultado creaba confusión.

Una solución mejor habría sido continuar tratando el tipo de contenido como el tipo de medio más externo, y usar un nuevo campo para describir el tipo anidado dentro de ese tipo. Desafortunadamente, la primera extensión fue desplegada antes de identificar el fallo.

REST identificó la necesidad de otra capa de codificación: aquella situada en un mensaje por un conector para mejorar la transferencia por la red. Esta nueva capa, llamada Transfer-Encoding en alusión a un mismo concepto de MIME, permite a los mensajes ser codificados para transferirse sin que esto implique que la representación está codificada por naturaleza. Transferir codificaciones puede ser añadido o quitado por los agentes que transfieren, por cualquier razón, sin cambiar la semántica de la representación.

5.7.3.2.3 Independencia semántica

Como se ha descrito antes, el análisis de un mensaje HTTP se ha separado de su semántica. El análisis del mensaje, incluyendo la búsqueda y procesado de los campos

de cabecera, ocurre de forma separada del proceso de análisis del campo de contenido. De esta manera los sistemas intermedios pueden procesar y reenviar rápidamente los mensajes HTTP, y las extensiones pueden ser desplegadas rápidamente sin influir esto en los analizadores existentes.

5.7.3.2.4 Independencia del transporte

Las primeras versiones de HTTP, incluyendo la mayoría de las implementaciones de HTTP/1.0, usaban el protocolo de transporte subyacente, con él indicaban el final de la respuesta de un mensaje. Un servidor indicaba el final de un mensaje de respuesta cerrando la conexión TCP. Desafortunadamente, esto constituye una condición de fallo considerable en el protocolo: un cliente no tiene modo alguno de saber si una respuesta ha finalizado o simplemente se vio truncada por un error en la red. Para solucionar esto, en HTTP/1.0 se incluyó un campo de cabecera que indicaba la longitud del contenido en bytes siempre que la longitud sea conocida.

Para HTTP/1.1 se definió la codificación para “partes”, con ella, para una representación cuyo tamaño es desconocido al comienzo de su generación (cuando se envía el campo cabecera), se permite dividirla en pedazos de los cuales se conocen su tamaño. Con este método también se permite enviar los metadatos al final del mensaje, permitiendo así crear metadatos opcionales al principio mientras se están generando, sin añadir tiempo de retardo.

5.7.3.2.5 Limites de tamaño

Una barrera frecuente para la flexibilidad de la capa de aplicación es la tendencia a sobre-especificar los límites de tamaño en los parámetros del protocolo. Aunque existen algunos límites parciales en los parámetros del protocolo (memoria disponible), especificando esos límites en el protocolo se restringe a todas las aplicaciones a los mismos límites, independientemente de su implementación. El resultado es que se obtiene un protocolo que no puede extenderse mucho de su creación original.

En el protocolo HTTP, no hay límites para la longitud del URI, del campo cabecera, de la longitud de la representación, o de la longitud de cualquier valor de un campo que consista en una lista de datos. Aunque los antiguos clientes Web tienen problemas bien conocidos con las URI de más de 255 caracteres, esto es suficiente para darse cuenta de que el problema está en la especificación de HTTP y no en limitar a todos los servidores.

Aunque no necesitaba inventar limitaciones artificiales, HTTP/1.1 necesitó definir un conjunto apropiado de códigos de estado de respuesta para indicar cuando un elemento de un protocolo dado es demasiado grande para que los servidores lo procesen. Dichos códigos de respuesta fueron añadidos en las condiciones URI-Solicitada demasiado grande, campo cabecera demasiado grande, y cuerpo del mensaje demasiado grande. Desafortunadamente, no hay manera de que un cliente indique a un servidor que puede tener límite de recursos, lo que conlleva problemas cuando un dispositivo con recursos

limitados, como puede ser una PDA, intenta usar HTTP sin un interfaz intermediario que posibilite la comunicación.

5.7.3.2.6 Control de Caché

Como REST trata de equilibrar la necesidad de eficiencia y tiempo de espera con la transparencia semántica del comportamiento del caché, es muy necesario que HTTP permita a la aplicación determinar los requerimientos de caché antes que imponerlos por si mismo. Lo más importante que tiene que hacer el protocolo es describir completa y exactamente los datos que se van a transferir, de manera que ninguna aplicación se vea engañada al pensar que tiene algo cuando realmente tiene otra cosa diferente. HTTP/1.1 hace esto añadiendo el control de caché y varios campos de cabecera.

5.7.3.2.7 Negociación de Contenido

Todos los recursos transforman una petición (que consiste en un método, campo cabecera de petición, y a veces una representación) en una respuesta (que consiste en un código de estado, campo de cabecera de la respuesta, y a veces una representación). Cuando una petición HTTP puede dar lugar a múltiples representaciones en el servidor, el servidor puede mantener una negociación del contenido con el cliente para determinar cuál es la representación que mejor se adapta a las necesidades del cliente. Esto es realmente una selección de contenido más que una negociación.

Figura 25: Negociación del contenido

Aunque hubo muchas implementaciones de la negociación del contenido desplegadas, no se incluyó en la especificación de HTTP/1.0 porque no existió un subconjunto interoperable en el momento en que se publicó. Esto fue en parte, debido una pobre implementación de NCSA Mosaic, la cual debía enviar 1Kb de información de preferencia en los campos de cabecera para hacer la negociación del recurso. Como

menos del 0,001% de todas las URI pueden negociar el contenido, el resultado aumentaba considerablemente el tiempo de retardo y aportaba unos beneficios muy pequeños, lo que condujo a que los navegadores posteriores evitaran la negociación del contenido.

La negociación guiada por el servidor ocurre cuando el servidor varía la representación de la respuesta por causa de una determinada combinación del código de estado en el campo cabecera del método de petición, o por cualquier variación extraordinaria en los parámetros. El cliente necesita ser notificado cuando esto ocurre, de manera que un caché pueda conocer cuando es semánticamente transparente usar una respuesta del caché para una petición futura, y también que un usuario pueda sustituir las preferencias detalladas. HTTP/1.1 introduce el campo Vary en la cabecera para este propósito. Vary simplemente lista las dimensiones del campo cabecera sobre las que una respuesta puede variar.

En la negociación guiada por el servidor, el usuario le dice al servidor lo que es susceptible de aceptar. El servidor, entonces, elige la representación que mejor se ajusta a las capacidades del cliente. Sin embargo, esto no es un problema manejable, porque requiere no solo información de lo que el usuario acepta sino también de cómo de bien acepta las características y cual era el propósito del usuario con la representación. Por ejemplo, si un usuario quiere ver una imagen en la pantalla, puede que prefiera un simple mapa de imágenes, pero el mismo usuario con el mismo navegador puede que prefiera una representación PostScript si lo que realmente quiere hacer es imprimirla. También depende de si el usuario ha configurado correctamente el navegador de acuerdo con sus preferencias en cuanto al contenido. En resumen, un servidor raramente podrá hacer afectiva la negociación guiada por el servidor, pero es la única forma automática definida por las primeras versiones de HTTP.

HTTP/1.1 añadió la noción de negociación guiada por el usuario. En este caso, cuando un usuario solicita un recurso negociable, el servidor responde con una lista de posibles representaciones. El usuario puede elegir cual es la mejor de acuerdo con sus propias capacidades. La información acerca de las representaciones disponibles puede ser suministrada por medio de una representación diferente, dentro de los datos de la respuesta, o como suplementaria a la respuesta que mejor se adapta. La última funciona mejor en la Web porque las interacciones adicionales solo llegan a ser necesarias si el usuario decide que una de las variantes es mejor. La negociación guiada por el usuario es simplemente es un reflejo automático de el modelo normal de servidor, lo que significa que puede tomar todas las ventajas del funcionamiento de REST.

Las negociaciones guiadas por el usuario y el servidor tienen la dificultad de comunicar las características actuales de las dimensiones de la representación (por ejemplo, decir si un navegador soporta tablas HTML pero no insertar elementos). Sin embargo, la negociación guiada por el usuario tiene las ventajas de no tener que enviar las preferencias en cada petición, teniendo así mayor información del contexto para hacer una decisión ante distintas alternativas, y no interferir con la caché.

Una tercera forma de negociación, es la negociación transparente, da el permiso a un caché intermediario de actuar como agente, para seleccionar la mejor representación. La petición puede ser resuelta internamente por cualquier otro caché, y por tanto es posible

que ninguna petición de la red sea hecha. Haciendo esto, sin embargo, están funcionando como negociaciones guiadas por el servidor, deben por tanto añadir la información adecuada para que otras caché no se equivoquen.

5.7.3.3 Métodos HTTP y su uso en REST

Usar los métodos HTTP GET, POST, PUT y DELETE, es suficiente para poder implementar cualquier Servicio Web. A continuación se adjunta la Tabla [7] en la que se indica la función de cada uno dentro de una comunicación REST.

MÉTODO FUNCIÓN

GET Solicitar recurso

POST Crear recurso nuevo

PUT Actualizar o modificar recurso

DELETE Borrar recurso

Tabla 8 Métodos REST

Todos los Servicios accesibles vía HTTP deben ser idempodentes [8], “Idempodente” significa que una vez que se le pasa un mensaje a un Servicio, no existen efectos adicionales si se pasa el mismo mensaje de nuevo. Por ejemplo, un mensaje cuya función es borrar datos, “Borra el recurso A”. Se puede enviar una vez, o diez veces consecutivas, pero todo debe quedar igual al final de cada procesado del mensaje. De la misma manera, GET es siempre idempodente, porque no afecta al estado. Los métodos GET, DELETE, PUT y POST que usa REST, están concebidos para ser idempodentes.

5.7.4 REST y XML

REST está especialmente orientado a los sistemas distribuidos de hipermedios. Tiene la necesidad de crear representaciones a partir de recursos, éstas pueden ser: gráficos, sonidos, páginas HTML, video o cualquier tipo de datos en general. Desde los comienzos de REST se apostó muy fuerte por XML como solución a la codificación de las representaciones, sobre todo debido su potencial a la hora de codificar cualquier tipo de datos. Esta relación entre REST y XML no es una imposición, es más bien una recomendación a tener en cuenta a la hora de codificar representaciones complicadas o que no están estandarizadas. Si un usuario realiza una petición para obtener información y por diversas causas no es conveniente o práctico usar XML, es algo totalmente razonable.

La recomendación de XML ha ayudado a poner un poco de orden en la situación caótica de los comienzos de REST

5.7.5 Repercusiones de usar HTTP y URI

Si unimos HTTP y URI a la naturaleza de REST, que apuesta por la transparencia en vez del encapsulamiento, obtenemos unas excelentes características de seguridad y tiempo respuesta.

La seguridad se ve mejorada debido a la facilidad que encuentran los Firewalls a la hora de aplicar una política de acceso. HTTP unido a REST es totalmente transparente, sólo con mirar la cabecera de un mensaje y observar el método, el origen y el destino, se puede decidir si se permite a un usuario el acceso a los recursos. Es bastante sencillo evitar código malicioso oculto dentro de la carga de un mensaje.

Figura 26: Comportamiento Firewall

Como se puede ver en la Figura [27], si llega una petición GET, y existen dudas sobre su intención, el administrador del servidor podrá estar tranquilo porque GET, por su propia definición, sólo puede solicitar recursos y por lo tanto no le está permitido modificar los datos del servidor.

La transparencia también tiene su repercusión en el tiempo de respuesta. Los sistemas intermedios pueden decidir rápidamente si una respuesta entregada por el servidor es “cacheable” (por tanto, debe ser almacenada), o si una petición del usuario puede ser respondida desde caché. Lo único que necesitan mirar es la cabecera del mensaje.

5.8 Cuestiones por resolver

En este apartado se va a exponer la opinión de algunos autores sobre algunos cabos sueltos o aspectos que deja REST en el aire a la hora de diseñar Servicios Web.

5.8.1 David Megginson

David Megginson es el director de Megginson Technologies, ha sido un miembro activo de las comunidades SGML y XML. Actualmente también pertenece a un grupo de trabajo sobre información XML en el W3C.

Este autor trata de plantear y dar solución a cuatro aspectos del diseño de servicios Web REST: la identificación de recursos, el descubrimiento de servicios, el significado de los enlaces y la normalización. En un último apartado habla de la carencia que tiene REST en cuanto a la estandarización de los tipos de contenido.

5.8.1.1 Cuestiones de un diseño REST [11]

REST ahora tiene un significado más amplio y es fácil de explicar: piezas de datos (probablemente codificados con XML) situadas en la Web, que manipulamos usando los métodos HTTP GET, PUT y DELETE (prácticamente CRUD, excepto que Create y Update se encuentran combinadas en PUT). Si Tratamos de explicar SOAP en una sencilla frase como ésta, veremos la diferencia que existe.

Esta simplicidad debe hacer sonar algunas alarmas. ¿Esconde REST algunas trampas? Los Restafarians (adeptos a REST) señalan que REST constituye las bases del éxito de la Web, pero eso es solamente la parte GET (y POST). Tenemos muy poca experiencia usando PUT y DELETE en las páginas Web normales, y menos todavía para mantener datos almacenados. Incluso los grandes servicios de ventas de Amazon y eBay usan sólo GET (y POST en el caso de eBay); de hecho, la mayoría de los firewalls vienen configurados por defecto para bloquear PUT y DELETE desde que los administradores Web los ven como posibles agujeros de seguridad.REST es más manejable que XML-RPC y WS-* a la hora de usar XML en la Web, pero hay algunos temas que debemos tratar antes. El mantenimiento de los datos no es fácil, y mientras que WS-* lo hace más difícil de lo que debe ser, ni el más simple de los modelos REST lo hace trivial. Vamos a estudiar algunos aspectos del diseño REST que son importantes:

Identificación Listar y descubrir recursos El significado de un enlace ¿Cuánta normalización? La palabra “C” (contenido)

5.8.1.2 Identificación

La primera cuestión que trataremos es que los Restafarians consideran que la identificación y localización son la misma cosa. Siguiendo con esto, veremos cómo hacer una identificación persistente en recursos XML. Por ejemplo, asumamos que http://www.example.org/airports/ca/cyow.xml es al mismo tiempo un identificador único de un objeto de datos XML y la localización de un objeto en la Web. Esto es un punto muy importante en REST. Según los Restafarians no debe haber

interfaces donde los identificadores están ocultos dentro de un objeto XML devuelto de una petición POST a URLs no relacionadas.

5.8.1.2.1 GET y PUT

Veamos un caso simple. Diremos que descargamos el fichero de datos XML de http://www.example.org/airports/ca/cyow.xml. Este sería el ejemplo:

<airport> <icao>CYOW</icao> <name>Macdonald-Cartier International Airport</name> <political> <municipality>Ottawa</municipality> <region>ON</region> <country>CA</country> </political> <geodetic> <latitude-deg>45.322</latitude-deg> <longitude-deg>-75.669167</longitude-deg> <elevation-msl-m>114</elevation-msl-m> </geodetic></airport>

Lo copiamos en un lápiz USB, lo traemos a casa desde el trabajo, lo copiamos en el ordenador portátil, y trabajamos con el fichero mientras estamos sin conexión durante un vuelo. El fichero ya no tiene una conexión directa con su URL: ha pasado por otras transferencias desde que usamos HTTP GET para descargarlo. ¿Cómo sabemos con qué estamos trabajando o dónde deberíamos ponerlo cuando terminemos?

Si esta información no debe permanecer online, algunas de las ventajas de REST se evaporan, porque ahora no podemos usar las tecnologías Web existentes. Como un identificador, la URL claramente forma parte del estado del recurso, y corresponde al fichero de datos XML; como localización, sin embargo, es una información superflua y corresponde sólo al nivel de protocolo (HTTP).

5.8.1.2.2 ¿Dónde va el identificador de documento?

Asumamos que hemos decidido que la URL es un identificador adecuado y pertenece a la representación XML. Ahora, ¿Cómo hacemos esto de una manera elegante? xml:id está fuera de la cuestión porque está diseñado solo para llevar un nombre XML que identifique una parte de un documento, no una URI que identifica el documento entero. Podríamos usar (o abusar) de xml:base, sería algo como esto:

<airport xml:base="http://www.example.org/airports/ca/cyow.xml"> ...</airport>

No sabemos exactamente como trataría con esto un procesador XLink. ¿Se resolvería la URL relativa “cyyz.xml” como http://www.example.org/airports/ca/cyyz.xml o como http://www.example.org/airports/ca/cyow.xmlcyyz.xml? También existe la posibilidad de que algunas APIs bastante experimentadas ya, “digieran” primero el atributo xml:base de manera que el código de la aplicación nunca lo viese. ¿Verá la gente que apoya el estándar XML que el uso de xml:base es legítimo?

Si xml:id no se puede usar, y xml:base da problemas, parece que no hay una manera estándar de identificar documentos XML REST, y cada tipo de documento XML necesitará su propia solución. ¿Necesita el mundo otro atributo del tipo xml:*?

Necesitaremos escuchar como los desarrolladores de REST han tratado la persistencia del identificador cuando éste es la URL.

5.8.1.3 Listar y descubrir recursos

El segundo tema que vamos a tratar es el descubrimiento de los recursos. Comenzaremos con un ejemplo que tiene fallos e intentaremos corregirlo.

Digamos que tenemos una gran colección de de datos XML con URLs como:

http://www.example.org/airports/cyow.xml

http://www.example.org/airports/cyyz.xml

Como todos comparten el mismo prefijo, sería razonable asumir que usar una operación HTTP GET en ese prefijo (http://www.example.org/airports/) devolverá una lista de enlaces a todos los datos (debemos reconocer que las URL son opacas y por tanto nadie debería caer en la cuenta de esto, pero sólo es un ejemplo):

<airport-listing xmlns:xlink="http://www.w3.org/1999/xlink" xml:base="http://www.example.org/airports/"> <airport-ref xlink:href="cyow.xml"/> <airport-ref xlink:href="cyyz.xml"/> <airport-ref xlink:href="cyxu.xml"/> ...</airport-listing>

Esto es un ejemplo maravilloso de REST porque muestra como un motor de búsqueda podría encontrar e indexar cada recurso XML. Sin embargo, alguien que haya trabajado en un sistema grande puede ver que hay un problema de escalabilidad (dejando de lado otros problemas de privacidad y seguridad). Para una lista de varias docenas de recursos, es una gran aproximación. Para una lista de varios cientos, es manejable. Para una lista de varios miles de recursos, empieza a tener un gran consumo de ancho de banda cada vez que alguien hace un GET, y para una lista de varios millones de recursos, es simplemente ridículo.

Las aplicaciones basadas en HTML diseñadas para humanos normalmente emplean una combinación de búsqueda y paginación para tratar de descubrir recursos de una gran colección. Por ejemplo, podríamos empezar especificando que estamos interesados sólo en los aeropuertos que se encuentran a 200km de Toronto, la aplicación devolvería una única página de resultados (los 20 primeros resultados), con un enlace para dejarnos ver la siguiente página si nos interesa.

¿Cómo funcionaría esto en una aplicación de datos basada en REST? Claramente, queremos usar GET en vez de peticiones POST, porque las búsquedas puras están libres de efectos colaterales. Presumiblemente, terminaremos añadiendo algunos parámetros de búsqueda para limitar los resultados: http://www.example.org/airports/?ref-point=cyyz&radius=200km&has-iap=yes

Esto no es exactamente el tipo de URL REST que hay en los ejemplos, pero es parecida a la que se usa en los servicios Web REST de Amazon, por lo que quizás no estemos tan desencaminados. Por supuesto, deberá haber alguna manera para que los sistemas conozcan cuales son los parámetros disponibles. Ahora, quizá, el resultado sea algo como esto (asumiendo 20 resultados en la página):

<airport-listing xmlns:xlink="http://www.w3.org/1999/xlink" xml:base="http://www.example.org/airports/?ref-point=cyyz&radius=500nm&has-iap=yes"> <airport-ref xlink:href="cyow.xml"/> <airport-ref xlink:href="cyyz.xml"/> <airport-ref xlink:href="cyxu.xml"/> ... <next-page-link xlink:href="http://www.example.org/airports/?ref-point=cyyz&radius=500nm&has-iap=yes&start=21"/></airport-listing>

Esto es un buen uso de REST, porque el recurso XML contiene su propia información de transición (como un enlace a la siguiente página). Sin embargo, es increíblemente feo. Presumiblemente, el mismo tipo de paginación podría funcionar con la colección entera cuando no hay parámetros de búsqueda, de manera que:

http://www.example.org/airports/ohttp://www.example.org/airports/?start=1

Deberían devolver las 20 primeras referencias a aeropuertos, seguidas de un link a http://www.example.org/airports/?start=21, que devolverá las siguientes 20 entradas y así sucesivamente. La potencia de REST y XLink está clara: es posible comenzar con una única URL y descubrir todos los recursos disponibles automáticamente, al contrario que WS-*, se realiza sin tener que tratar con voluminosas especificaciones como UDDI y WSDL.

5.8.1.4 El significado de un enlace

El verdadero corazón de REST en su sentido original (todo debe tener una URL) y su sentido más popular y amplio (HTTP + XML como alternativa a los servicios Web), es “enlazar”. REST insiste en que cualquier información que se pueda recuperar debe tener una única dirección que podamos hacer circular, de la misma manera que podemos pasar un número de teléfono o una dirección de e-mail. Esas direcciones hacen posible enlazar recursos (páginas HTML o en el futuro, ficheros de datos XML) en la Web, de manera que las personas o los agentes software puedan descubrir páginas nuevas siguiendo enlaces desde otros existentes.

5.8.1.4.1 La vieja escuela del hipertexto

Pero, ¿Qué significa enlace? Esta cuestión afecta mucho a cualquiera que escriba software REST de propósito general, como motores de búsqueda, navegadores, o herramientas de bases de datos, que no están diseñadas para trabajar con un simple vocabulario de marcas XML. Los especialistas de hipertexto pre-HTML creían que los enlaces podían tener diferentes significados, querían proporcionar una manera de que el autor los especificara; escondidos en la sombra durante la revolución de la Web de los años 1990s, la vieja escuela trató de añadir a XLink el universalmente ignorado atributo xlink:type. ¿Necesitamos xlink:type para el procesado de datos XML en un ambiente de trabajo REST? La respuesta es que no, de hecho, si nos fijamos, enlazar un recurso externo desde un documento HTML siempre significa la misma cosa:

Es muy difícil pensar en excepciones. Por ejemplo, consideremos estos enlaces de un documento HTML:

<p>During the <a href="http://en.wikipedia.org/wiki/Renacimiento">Renacimiento</a> ...</p><img alt="Illustration of Galileo" src="galileo.jpg"/><script src="validate-form.js"/>

En cada caso, el elemento que contiene el atributo del enlace, proporciona algo de algún otro lugar. Obviamente, causa distintos comportamientos del navegador. El dibujo se insertará en el documento mostrado automáticamente, mientras que la entrada Renacimiento de Wikipedia no lo hará. Pero en ambos casos, las cosas que se enlazan

representan algo más completo: el artículo de Wikipedia sobre el Renacimiento es más completo que la frase “Renacimiento” y la imagen galileo.jpg es más completa que el texto alternativo “Ilustración de Galileo”

5.8.1.4.2 La nueva escuela XML

Exactamente los mismos principios se aplicarán a los enlaces en los ficheros de datos XML, como en este ejemplo:

<person xml:base="http://www.example.org/people/e40957.xml" xmlns:xlink="http://www.w3.org/1999/xlink"> <name>Jane Smith</name> <date-of-birth>1970-10-11</date-of-birth> <employer xlink:href="http://www.example.org/companies/acme.xml">ACME Widgets, Inc.</employer> <country-of-birth xlink:href="http://www.example.org/countries/ca.xml">Canada</country-of-birth></person>

Toda la información disponible para el nombre de la persona es la cadena “Jane Smith”, y toda la información disponible para la fecha de nacimiento es la cadena “1970-10-11”; sin embargo, hay información más completa sobre el empleado en http://www.example.org/companies/acme.xml, y hay información más completa sobre el país de nacimiento en http://www.example.org/countries/ca.xml. Parece que los enlaces unidireccionales como estos que se usan en la Web siempre conducen hacia un incremento de información canónica. Si un elemento XML tiene un atributo de enlace, entonces, ¿Podemos asumir que el documento XML entero representa una versión más pequeña de la información disponible externamente por el enlace? De ser cierto, ¿Podemos ganar mucho añadiendo xlink:role a la mezcla?

5.8.1.4.3 Futuro

Si realmente enlazar resulta tan sencillo, podremos hacer grandes cosas con datos XML y REST incluso si no estamos de acuerdo con una codificación común del contenido. Esto podría ser enormemente valioso: los documentos Web tuvieron una gran acogida precisamente porque la codificación del contenido se estandarizó mediante HTML. Si pudiésemos hacer lo mismo con los documentos Web XML sin tener que forzar a todo el mundo a encajar sus datos en algo como RDF o XTM, se podría conseguir suficiente gente que lo usara para que la idea funcionase.

5.8.1.5 ¿Cuánta normalización?

¿Cuánto se deben normalizar los ficheros de datos XML devueltos por una aplicación Web REST? Por ejemplo, si una aplicación devuelve información sobre la película Sixteen Candles, ¿Debería ponerse toda la información importante en un único fichero XML como este?

<film> <title>Sixteen Candles</title> <director>John Hughes</director> <year>1984</year> <production-companies> <company>Channel Pictures</company> <company>Universal Pictures</company> </production-companies></film>

O ¿debería enlazar a diferentes documentos XML que contengan información sobre las personas, compañías y el resto de datos?

<film xml:base="http://www.example.org/objects/014002.xml" xmlns:xlink="http://www.w3.org/1999/xlink"> <title>Sixteen Candles</title> <director xlink:href="487847.xml"/> <year>1984</year> <production-companies> <company xlink:href="559366.xml"/> <company xlink:href="039548.xml"/> </production-companies></film>

Presumiblemente, el servidor REST está creando la información XML desde una base de datos relacional que esté normalizada, por lo que el mantenimiento de los datos no es un problema. Aún así, cada ejemplo tiene sus desventajas.

En el primer ejemplo, la aplicación cliente no puede estar segura de que dos películas diferentes estén referidas al mismo director o productor, o de que alguna otra pueda tener el mismo nombre. También será difícil que el servidor pueda manejar una petición PUT para actualizar la base de datos normalizada.

En el segundo ejemplo, la aplicación cliente tendrá que realizar un gran número de peticiones GET para juntar suficiente información incluso para la aplicación más básica.

¿Es la mejor solución imitar a HTML? Los enlaces HTML normalmente incluyen una referencia a recursos externos y una breve descripción de ese recurso (por ejemplo, el

texto azul en el que solemos pinchar para acceder al enlace). No hay ninguna razón por la que los ficheros XML de una aplicación REST no puedan hacer lo mismo, combinar las ventajas de las aproximaciones normalizadas y no-normalizadas, como en este ejemplo:

<film xml:base="http://www.example.org/objects/014002.xml" xmlns:xlink="http://www.w3.org/1999/xlink"> <title>Sixteen Candles</title> <director xlink:href="487847.xml">John Hughes</director> <year>1984</year> <production-companies> <company xlink:href="559366.xml">Channel Pictures</company> <company xlink:href="039548.xml">Universal Pictures</company> </production-companies></film>

Ahora, una aplicación cliente REST no necesita solicitar ficheros de datos extra solamente para encontrar el nombre del director o de la productora, pero si sabe donde debe mirar para conocer información más completa. También puede usar la URL del enlace como identificador para evitar la ambigüedad en la gente y las compañías (las que son las mismas o sólo coincide el nombre). La aproximación además les será familiar a los desarrolladores Web que decidan usar REST para solicitar datos.

5.8.1.6 La palabra “C” (contenido)

Ahora que estamos cerrando las cuestiones de diseño, debemos hablar sobre el mayor problema de REST: el contenido.

Los principios de REST nos cuentan como manejar los recursos, pero no lo que podemos hacer con ellos. Este problema no lo comparten otras aproximaciones de red: XML-RPC define lo que significa el contenido XML hasta el punto de que se puede serializar y deserializar automática e invisiblemente; SOAP permite en principio cualquier tipo de carga XML (asumiendo que se envuelve en el sobre SOAP), aunque la mayoría de la gente usa la codificación por defecto de SOAP (que también puede ser serializada y deserializada automáticamente). REST, por otra parte, es pura arquitectura y no menciona directamente al contenido. Los adeptos a REST presumen de que ya hay aplicaciones REST funcionando como son Amazon, eBay o Flickr, pero los desarrolladores rápidamente entienden que no van a conseguir ningún beneficio: cada aplicación REST requiere sus propios mecanismos, porque usa diferentes formatos de contenido. Si usaran XML-RPC o SOAP, habría muchas librerías estándar que simplificarían el trabajo de los desarrolladores y se podría compartir el código.

En términos prácticos, ¿Es REST sólo una palabra de marketing? Los defensores de REST pueden argumentar que la carencia de una estandarización del contenido es algo beneficioso, porque hace que la arquitectura sea más flexible a la hora de tratar con cualquier tipo de recurso, desde un fichero XML hasta una imagen, un video o una

página HTML. Por otra parte, la carencia de un estándar en el formato del contenido dificulta hacer cosas útiles con los recursos una vez que los hemos solicitado. Ya se han propuesto candidatos para la codificación XML estándar de REST, incluyendo RDF y XTM, aunque parece que ninguno tendrá éxito porque RDF (el líder) nunca ha funcionado correctamente con la mayoría de especificaciones basadas en XML como XQuery o XSLT.

5.8.1.6.1 Estandarizando el contenido XML de REST en bits y piezas

La alternativa es estandarizar el contenido en bits y piezas. En vez de tratar con un formato exhaustivo de codificación de datos, podemos intentar usar un estándar de marcas para los bits, que podamos usar en cualquier tipo de documentos XML. Ahora vamos a exponer algunas posibilidades:

xlink:ref y xml:id para los enlaces

Usando el atributo xlink:href es posible que programas como los “spider” localicen fácilmente los enlaces sin importar el tipo de documento. Junto con xlink:ref, xml:id permite a los enlaces apuntar a fragmentos de los documentos XML de manera sencilla.

<data> <person xml:id="dpm"> <name>David Megginson</name> <person> <weblog> <title>Quoderat</title> <author xlink:href="#dpm"/> </weblog></data>

Esta característica es muy importante porque REST está basado en los enlaces. La carencia de un mecanismo estándar para los enlaces acabaría con REST incluso antes de que comenzase.

xml:base para la identificación de documentos

De manera similar, el atributo xml:base proporciona un identificador y localizador de documentos de datos XML. Un atributo xml:base adjunto al elemento principal, nos da una URL base para resolver enlaces relativos en los documentos y un identificador global para el documento en sí.

<data xml:base="http://www.example.org/data/foo.xml"> ...</data>

xsi:type para los tipos de datos

¿Necesitamos tipos de datos para todo en XML? El uso de esquemas externos suele ser una mala idea por razones de funcionamiento y seguridad. Si queremos crear un tipo para todo (al menos para los tipos de datos simples), debemos hacerlo en el propio documento usando algo similar al atributo xsi:type.

<start-date xsi:type="xsd:date">2005-02-23</start-date>

Hacerlo de esta manera suele ser algo inofensivo.

5.8.2 ebPML.org

ebPML es un sitio de Internet dedicado a los estándares, tecnologías y computación orientada a Servicios.

El grupo ebPML.org [12] hizo una crítica a REST en la que determinaba que no era válido para soportar aplicaciones B2B por las siguientes razones:

State Alignment: REST no ofrece ninguna pista para conseguir la alineación del estado. Eso no importa mucho en la Web, sin embargo, no funciona en los escenarios de negocios reales. Siempre que Amazon utilice una API basada en cliente/servidor, las cosas funcionarán bien porque un cliente recibiendo una respuesta es suficiente para conseguir una alineación del estado. Pero tan pronto como Amazon cambie para poder soportar escenarios de negocio más complejo, esto se convertirá en un problema más grande y SOAP será necesario.

Interacciones Peer-to-Peer: REST ofrece esencialmente un modelo cliente/servidor con tantas interacciones sin estado como sea posible entre el cliente y el servidor. Las interacciones de negocios son Peer-to-Peer, como es el caso de las definidas en OASIS/ebBP. Una interacción de Amazon involucra por lo menos a cuatro partes (comprador, Amazon, transporte y vendedor). Esas partes necesitan compartir el nivel de contexto del estado de la interacción. Esas ideas están totalmente fuera del ámbito de REST.

Estado parcial: REST asume que la representación del estado se transfiere libremente entre el cliente y el servidor. Esto puede que sea cierto en las páginas Web, pero no es cierto en los negocios Web. Es tremendamente raro que una parte transfiera completamente el estado de un objeto de negocio y la otra parte lo adquiera y actualice

su estado. En este punto es en el que se hacen necesarios nuevos verbos. Esto es lo que realmente está haciendo Amazon con los carros de la compra.

En resumen, REST no es una arquitectura válida para los servicios B2B (business to business).

5.9 Conclusiones

En este capítulo ha quedado recogida una visión actual del estilo de arquitectura REST. La base del capítulo ha sido la disertación de Roy Thomas Fielding, aunque también se han añadido algunos detalles del funcionamiento que surgieron posteriormente. En el siguiente capítulo se intentará dar una visión general del debate que ha existido en la Web entorno a la comparación entre REST y SOAP. Se expondrán los artículos más relevantes que se han escrito hasta el momento.

6 DEBATE REST-SOAP

En este capítulo se pretende dar una visión general del debate que ha existido en la Web entorno a la comparación entre REST y SOAP. Se exponen los artículos más importantes que se han escrito hasta el momento.

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. Aún 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 estilo de arquitectura orientado a RPC, 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.

En el debate de comparación entre REST y SOAP, la mayoría de los desarrolladores de aplicaciones Web toman posiciones muy extremas a favor de uno u otro. Los afines a SOAP, suelen pronunciarse diciendo que SOAP es más flexible que REST a la hora de implementar servicios Web y muestran como un defecto de REST la restricción “sin estado”, mientras que los adeptos de REST (también llamados Restafarians), critican la escasa transparencia de SOAP y opinan que hace las cosas más difíciles de lo que de verdad son, dicen que SOAP da “un paso hacia delante y dos hacia atrás”. Además opinan que SOAP puede suponer un problema porque puede dar lugar a la creación de agujeros de seguridad en las implementaciones HTTP. .

Este tema ha sido ampliamente discutido en la red durante los últimos años. Ahora expondremos las opiniones de los autores más importantes que se han pronunciado al respecto.

6.1 PAUL PRESCOD

Paul Prescod es un programador independiente de las tecnologías basadas en el lenguaje de marcas. Trabajó en un grupo del W3C para escribir la familia de estándares de XML y escribió el libro más importante sobre la familia de estándares: The XML Handbook.

Fue uno de los primeros autores en estudiar la disertación de Roy Fielding y emitir su juicio respecto al debate REST-SOAP. A continuación expondremos dos artículos especialmente importantes.

6.1.1 Raíces del debate REST-SOAP [14]

Este artículo hace un resumen de lo que es REST, y su comparación con SOAP. Explica que WSDL puede convertirse en un cuello de botella. Además, incide en los beneficios de usar URI para tener un sistema de direccionamiento global.

Fielding desarrolló las ideas de REST pero no argumentó si REST o HTTP constituían unas bases suficientes para una arquitectura de servicios Web. Él nunca ha dicho si creía que era necesaria una arquitectura de servicios Web distinta de la arquitectura Web. Algunos han llegado a la conclusión de que no es necesaria. Nosotros sentimos que la arquitectura Web y REST son ya unas bases viables para la arquitectura de servicios Web.

REST enfatiza:

Escalabilidad de los componentes de interacción. Generalidad de las interfaces. Independencia en el desarrollo de componentes. Sistemas intermedios para reducir la el tiempo de interacción, mejorar la

seguridad, y encapsular los sistemas de herencia.

El primero, “escalabilidad de los componentes de interacción”, ha sido incuestionablemente logrado. La Web ha crecido exponencialmente sin degradar su funcionamiento. Una faceta de la escalabilidad se muestra en la variedad de clientes software que pueden acceder y ser accedidos a través de la Web.

El segundo objetivo, “generalidad de las interfaces”, es la clave que hace que REST plantee unas bases mejores que SOAP para el marco de trabajo de los servicios Web. Cualquier cliente HTTP puede hablar con cualquier servidor HTTP sin necesidad de configuración. Esto no le ocurre a SOAP. Con SOAP, deben conocerse los nombres de los métodos, el modelo de direccionamiento y los modelos de procesamiento de cada servicio en particular. Esto ocurre porque HTTP es un protocolo de aplicación mientras que SOAP es un marco de trabajo para el protocolo.

Fielding pide “independencia en el desarrollo de los componentes” porque es necesario a la hora de tratar con Internet. Las implementaciones del cliente y servidor pueden tardar en desarrollarse años e incluso décadas. Los antiguos servidores HTTP podrían no actualizarse y los nuevos clientes deben poder hablar con ellos. Los antiguos clientes podrían necesitar hablar con los nuevos servidores. Diseñar un protocolo que permita esto es bastante difícil. HTTP se hace extensible por medio de las cabeceras, a través de las nuevas técnicas de generación de URI, a través de la capacidad para crear nuevos métodos y a través de la capacidad de crear nuevos tipos de contenidos.

El último objetivo de REST es la “compatibilidad con los sistemas intermedios”. Los sistemas intermedios más famosos son los Web proxies. Algunos proxies hacen el papel de caché para mejorar el funcionamiento. Otros mejoran las políticas de seguridad. Otro tipo de sistemas intermedios muy importantes, son los gateways, que encapsulan sistemas que originalmente no son Web.

REST consigue esos objetivos aplicando cuatro constantes:

Identificación de recursos Manipulación de recursos a través de sus representaciones Mensajes auto-descriptivos Hipermedios como el motor del estado de la aplicación

La identificación de recursos siempre se hace por medio de URI. HTTP es un protocolo centrado en URI. Los recursos son los objetos lógicos a los que les mandamos mensajes. Los recursos no pueden ser directamente accedidos ni modificados. En vez de eso, trabajamos con representaciones de ellos. Cuando usamos el método HTTP PUT para enviar información, se toma como una representación del estado en el que nos gustaría que estuviese el recurso. Internamente el estado del recurso puede ser cualquier cosa desde una base de datos relacional hasta un simple texto plano.

REST obliga a que los mensajes HTTP sean tan auto-descriptivos como sea posible. Esto permite que los sistemas intermedios puedan interpretar los mensajes y mejoren el comportamiento con los usuarios. Uno de los modos con los que HTTP realiza esto es estandarizar los métodos, las cabeceras y los mecanismos de direccionamiento. Por ejemplo los servidores caché conocen que por defecto GET es “cacheable” (porque no puede tener efectos colaterales al solicitar una representación de un recurso). Por el contrario POST es no-cacheable por defecto. HTTP es un protocolo sin estado, y si se usa correctamente, es posible interpretar cada mensaje sin conocer los mensajes que existieron anteriormente, ni los que le seguirán. Por ejemplo en vez de usar “loggin in” de la manera que lo hace FTP, HTTP envía la información nombre/contraseña en cada mensaje.

Finalmente. REST describe un mundo en el que cada hipermedio es el motor del estado de la aplicación. Esto significa que el estado actual de una aplicación Web particular debe estar capturado en uno o más documentos de hipertexto, residiendo en el cliente o en el servidor. El servidor conoce el estado de sus recursos pero no va almacenando los pasos de cada “sesión” de un cliente. Es el cliente quien conoce la misión que se necesita completar. Es responsabilidad del cliente ir navegando de recurso en recurso, recopilando la información que necesita y cambiando el estado cuando lo necesita.

Hay millones de aplicaciones Web que implícitamente hacen uso de las restricciones de HTTP. Hay una disciplina detrás de cada sitio Web escalable y que puede ser aprendida de varios estándares y documentos de arquitectura Web. También es cierto que muchos sitios Web comprometen uno o más de esos principios para hacer cosas que van en contra de la arquitectura como puede ser almacenar los movimientos que hace un usuario en un sitio Web. Este almacenamiento es posible dentro de la infraestructura Web, pero influye negativamente en la escalabilidad porque transforma lo que es esencialmente sin conexión en algo basado en conexión.

Aunque REST y HTTP hace uso de muchas reglas y principios, algunas de ellas pueden colapsar. Por ejemplo si queremos hacer un sitio HTML de gran calidad, ¿Cómo debemos hacerlo? La respuesta, es que podemos cambiar y usar representaciones XML.

Los defensores de REST han llegado a creer que esas ideas son tan aplicables para los problemas de integración de las aplicaciones como para los problemas de integración del hipertexto. Fielding es bastante claro cuando dice que REST no es la solución

absoluta para todo. Señaló que su diseño de las características no sería apropiado para otro tipo de aplicaciones de red. Nada más lejos, los que han elegido adoptar REST como modelo de servicios Web, sienten que al menos articula una filosofía de diseño con sus puntos fuertes, sus puntos débiles y áreas donde se puede aplicar.

Por el contrario, la arquitectura de servicios Web convencional ha sido conducida sin rumbo. Sus desarrolladores han hecho hincapié en algunas ideas pero han ignorado otras. Lo peor es que han olvidado adoptar las ideas más importantes que hacen que la Web funcione bien.

SOAP ahora no es muy útil. Después de su primera versión, hubo un periodo enfocado al crecimiento en la extensibilidad. Las cabeceras SOAP cada vez se hicieron más prominentes y sofisticadas. SOAP desarrolló un mecanismo para poder correr bajo múltiples protocolos de transporte. SOAP creció de ser un protocolo a ser un marco de trabajo para protocolos. En otras palabras, SOAP creció y cambió tan drásticamente que ahora los defensores de SOAP pueden despreciar una característica (el tipo de sistema de SOAP) que una vez fue considerada la principal razón de la existencia de SOAP. Sus objetivos han cambiado tan drásticamente que la palabra SOAP pasó de ser un acrónimo de “Simple Objet Access Protocol” a ser simplemente un nombre sin significado.

Los cambios más recientes se han hecho para responder a las críticas de los defensores de REST. Se señaló que SOAP abusa de HTTP y falla al integrarse correctamente en la arquitectura Web. Esos cambios todavía no han sido desarrollados en ninguna herramienta y puede que nunca lo hagan. Pero los cambios son por lo menos un signo de que hay esperanza.

Una de las mayores diferencias entre el punto de vista de REST y de SOAP es que REST ve la Web como un sistema de información por sí misma y dice que los otros sistemas deberían estar integrados en el sistema de información por medio de gateways.

Lo más importante de un espacio de información Web compartida es la idea de URI. Los servicios Web basados en SOAP nunca han adoptado la noción de la Web como un espacio de información compartida y por ello nunca han adoptado completamente el modelo Web basado en URI. Ellos, por el contrario, siempre han asumido que cada aplicación debe definir su propio espacio de nombres.

Los estándares de servicios Web nunca fueron diseñados para usar URI como identificadores de recurso y de hecho WSDL hace que esto sea esencialmente imposible. No hay ninguna manera de decir en WSDL que un elemento particular de un mensaje SOAP representa una URI y que la URI apunta a un servicio Web. Por lo tanto cada WSDL describe solo un recurso Web y no proporciona ningún método para describir enlaces a otros recursos. SOAP y WSDL usan URI solo para direccionar un punto final de gran importancia que gestiona todos los objetos dentro de el. Por ejemplo, para enviar un mensaje a una cuenta en particular, debe hacerse algo como esto:

bank = new SOAPProxy("http://.....")

bank.addMoneyToAccount(account 23423532, 50 dollars)

Para conseguir el balance asociado a una cuenta, debe hacerse algo como esto:

bank = new SOAPProxy("http://.....")bank.getAccountBalance(account 23212343)

Hay que hacer notar que la cuenta por si sola no es directamente direccionable. No tiene URI, solo un número de cuenta. Sólo se puede acceder a la cuenta a través del servicio. También debemos darnos cuenta de que los números de cuenta del banco constituyen un espacio de nombres, distinto del espacio de nombres de las URI de la Web. En la versión del servicio centrada en la Web, las cuentas deberían ser individualmente direccionables y cada una debería tener una URI.

Ahora vamos a hacer una analogía. Supongamos que estamos viviendo temporalmente en un hotel. El hotel puede no tener conexiones telefónicas directas con el exterior. Para llamar a una habitación debemos contactar con el operador primero (esto es como contactar con el punto final de SOAP) y después pedir que nos conecten con la habitación. Ahora imaginemos que hay un servicio externo al que queremos acceder. Es un servicio automatizado de Horóscopo. Intentamos acceder al servicio pero cuando nos preguntan el número de teléfono, nos damos cuenta de que no solo hay un número que podamos proporcionar. El servicio debe contactar primero con el operador y después el operador pasará la llamada hasta nosotros. Obviamente, un ordenador en el otro extremo de la comunicación no es capaz de entender esto, y el operador no sabrá a quien pasar la llamada.

Si todo el mundo viviese en un hotel como este, el servicio de horóscopo sería prácticamente imposible. Una aplicación particular del teléfono dejaría de existir.

Hay que darse cuenta de que el problema no es tan obvio en el diseño de cada sistema por separado. Sólo cuando tratamos de unir ambos sistemas es cuando desearíamos haber usado la sintaxis del estándar internacional de direccionamiento telefónico. Los puntos finales de SOAP son como el operador. Los objetos con los que trabajan (recibos, cuentas de banco) son las habitaciones del hotel. Los datos están a la merced de los puntos finales de SOAP. Si las interfaces de los servidores y clientes no están perfectamente alineadas, no se pueden comunicar. Una tercera parte que sea una aplicación que intenta integrarlas, tendría que extraer explícitamente la información de un servicio y ponerla en el otro. Esto no es una buena solución porque la tercera parte tendría que ser la responsable del intercambio de información. Idealmente sería preferible introducir los dos elementos de datos de tal manera que permitan a cada uno ser informado de los cambios de estado del otro.

En contraste con esto, HTTP recomienda fuertemente el uso de URI como identificadores. De hecho, la arquitectura Web anima a usar URI que puedan ser resueltas en documentos. Comúnmente esto significa URIS “http:”. URI es el elemento

que unifica el concepto de HTTP. Podemos inventarnos nuestras propias cabeceras e incluso en algunos casos nuestros propios métodos. Podemos usar cualquier tipo de contenido en el cuerpo (o ninguno) pero siempre debemos enviar una URI como el recurso objetivo de cada petición HTTP.

Esta elección tiene consecuencias reales. Si dos servicios HTTP se pueden poner de acuerdo en la representación de una información (por ejemplo RSS o SAML) entonces esos dos servicios pueden comunicarse sobre esos recursos de información simplemente pasando URI a los recursos. Por ejemplo, si tenemos un documento RSS representando la información de un blog, podemos introducirlo en un sistema de visionado de blogs como Meerkat simplemente manejándolo como una URI. Meerkat no necesita saber cual es el mecanismo de direccionamiento porque está estandarizado. Meerkat tampoco necesita saber los métodos que usamos para conseguir la información porque el método HTTP “GET” está implícito. También podemos imaginar el servicio contrario. Podemos pedirle a Meerkat que use un RSS haciendo un PUT a una dirección que especifiquemos.

En muchos aspectos, el estandarizado modelo SOAP difiere de las ideas básicas de lo que llamamos la filosofía XML. La familia de estándares XML presume de que toda la información útil está disponible en un formato XML en una dirección estandarizada. Las tecnologías de servicios Web se usan casi siempre para configurar diferentes espacios de direcciones que casi nunca son direccionables mediante URI. Como ejemplos de esos distintos espacios de direcciones están UDDI y Microsoft's .NET My Services. Esos espacios de direcciones son fundamentalmente incompatibles con las tecnologías XML centradas en URI.

Hay una razón para el fallo de SOAP en el direccionamiento. Si SOAP admitiese que la sintaxis de direccionamiento para SOAP fuese URI, eso sería equivalente a decir que SOAP está diseñado sólo para ser usado en la Web. Sin embargo, los defensores de SOAP son muy claros en el hecho de que los protocolos Web y los modelos de direccionamiento Web, solamente sirven como transporte para SOAP. La Web es un conductor de taxi y su única función es llevar SOAP de un lado a otro. El mensaje SOAP puede salir del taxi y entrar en otro vehículo para proseguir otra etapa de su viaje. En términos técnicos, SOAP hace un túnel sobre la Web. Esto no es para lo que se diseñó la Web.

El punto de vista de REST es que la Web por si sola es un sistema de información increíblemente escalable y bien diseñada. Fue explícitamente diseñada para integrar distintos sistemas de información. Pero la Web lo hace a su manera, uniéndolo todo en un único sistema de nombres y recomendando el uso de un único protocolo.

La Web es un tipo de mundo unificado, global y donde todo el mundo mapea sus sistemas con el mismo modelo, usando el mismo esquema de direccionamiento, un reducido número de protocolos globales que todo el mundo entiende, formatos para la información compartida y vocabularios XML. No tiene mucho sentido adoptar la parte menos potente de la infraestructura Web (la sintaxis del método HTTP POST) e ignorar la parte más potente: El espacio de nombres URI y el modelo de manipulación de recursos estandarizados.

La relación entre REST y SOAP/WSDL es similar a la que existe entre XML y SGML. XML era prescriptita: “debes usar Unicode”. SGML era descriptiva “puedes usar cualquier carácter pero debes declararlo”. XML: “Debes usar URI para los identificadores”. SGML “Puedes usar cualquier clase de identificador (nombre de fichero, clave de la base de datos…)”.

SOAP ignora cosas que hemos aprendido de XML y la experiencia de la Web. Aún así, SOAP continúa ganando adeptos en la industria y el comercio.

Los seguidores de REST deben ver SOAP como una pregunta más que como una respuesta. La pregunta es “¿Cómo hacemos que la Web haga las cosas de los Servicios Web? El hecho de que la gente sienta que necesita SOAP indica que no están satisfechas con HTTP. Por tanto hay que evaluar las cosas que se supone que SOAP añade a HTTP.

Hay algunos temas que surgen cuando los adeptos a REST hablan con los adeptos a SOAP:

Asincronía:

Esto significa diferentes cosas para la gente, pero la acepción más común es que dos programas que se comunican (por ejemplo cliente y servidor) no deben estar en constante comunicación mientras que uno de ellos esté realizando cálculos de gran peso. Debe haber alguna manera para que una parte de la comunicación pueda avisar a la otra. SOAP no soporta esto directamente pero puede ser usado de una manera asíncrona si el transporte que utiliza es asíncrono. Esto todavía no está estandarizado pero algún día lo estará. Hay una gran variedad de aproximaciones para hacer HTTP asíncrono. Se ha propuesto la estandarización, una de esas especificaciones es “HTTPEvents”.

Enrutamiento:

Los mensajes HTTP están enrutados desde los clientes hasta los servidores proxies. Esto es un tipo de enrutamiento controlado por la red. También hay algunos casos en los que tiene sentido que el cliente controle el enrutamiento explícitamente, definiendo el camino que debe seguir un mensaje entre los nodos. Algunas investigaciones de REST están trabajando con variantes del enrutamiento de SOAP para esto.

XML:

Actualmente estamos en una situación donde XML es un requisito para la creación de nuevas especificaciones tanto si añade valor como si no. El grupo de trabajo que está estandarizando SOAP dentro del W3C se llama “XML Protocol Working Group”. En el mundo actual es probable que las tecnologías pre-XML se reinventen al estilo XML sólo porque está de moda.

Fiabilidad:

La fiabilidad es otra palabra que significa diferentes cosas para la gente. Para la mayoría de la gente significa entregar un mensaje una y solo una vez. Esto es relativamente fácil de conseguir con HTTP, pero no es una característica implícita. Lo que podría decirse

que es peor es la cuestión de que la fiabilidad garantizada va en contra de las redes a gran escala y tratar de conseguirla puede degradar el funcionamiento.

Seguridad:

Aunque HTTP tiene características de seguridad, es útil compararlas con las características que surgen como parte de WS-Security.

Extensibilidad del modelo:

SOAP tiene un modelo de extensibilidad que permite al creador de un mensaje SOAP ser muy explícito sobre si comprender una parte del mensaje es opcional o necesario. También permite a las cabeceras que sean interpretadas por sistemas intermedios en particular (como proxies o cachés). Hay una extensión de HTTP con muchas de estas ideas (de hecho la versión de SOAP probablemente esté basada en la versión HTTP) pero no es tan conocida ni está sintácticamente clara.

Descripción del servicio:

SOAP tiene WSDL pero HTTP no tiene nada parecido porque REST es un modelo centrado en documento. La descripción de servicios REST puede surgir de los lenguajes esquemáticos y en particular de los lenguajes de esquema semántico como DAML. También sería posible usar la siguiente versión de WSDL de manera adaptada como un tipo de lenguaje de descripción para los recursos HTTP.

Familiaridad:

Las tecnologías de servicios Web están diseñadas para ser tan flexibles que podemos usarlas siempre que estemos acostumbrados a programar. Los que no tienen experiencia con la programación en red pueden usar las variantes de RPC y usar las funciones como si fuesen locales. Los que tienen experiencia en el intercambio de mensajes, pueden usar unidireccionalmente SOAP para envolver sus mensajes. Los defensores de REST pueden usar una extensión de HTTP. Ninguno de esos tres grupos de programadores podrá interoperar con los demás.

Mirando hacia el futuro, hay tres posibles futuros. En uno, las críticas de REST sobre la filosofía de SOAP resultan ser incorrectas. El modelo de SOAP volvería a ser suficientemente bueno y el uso de REST se limitaría a ser el hipertexto de la Web. En un segundo escenario, la metodología de SOAP revelaría gradualmente sus defectos hasta que fuesen intratables. REST o algo parecido se convertiría en la arquitectura dominante y SOAP estaría relegado a tener un papel mucho menos importante. En el tercer escenario, encontraríamos una manera de que ambas arquitecturas trabajasen juntas. Cada una podría tratar diferentes problemas e incluso podrían interoperar.

¿Puede ganar un solo protocolo? Los negocios electrónicos van a necesitar algo más que software orientado a RPC o a mensajes. Todos los negocios tendrán que estandarizar sus modelos de direccionamiento y compartir una interfaz común con el

resto de negocios. SOAP no hace esto por si mismo, en este aspecto, hace más daño que la ayuda que ofrece.

Para que los negocios puedan interoperar sin necesidad de programar manualmente los enlaces con otros negocios, necesitarán estandarizar los protocolos antes que inventar nuevos. Tendrán que estandarizar un modelo de direccionamiento antes que inventar uno nuevo. REST propone un alto grado de estandarización. Los servicios Web estarán estancados hasta que se estandaricen en una arquitectura unificada, y REST es esa arquitectura. Si esto es cierto, entonces no importa si gana REST o SOAP, porque SOAP viviría dentro de la arquitectura REST para servicios Web.

¿Pueden coexistir REST y SOAP? Recientemente SOAP ha tomado una dirección que le acerca a REST, pero también conserva su núcleo basado en RPC. La cuestión por tanto no es si SOAP y REST pueden coexistir. Pueden. Pero si la visión del mundo basado en REST es correcta, entonces todo el proyecto SOAP/WSDL sería un error. ¿Por qué necesitamos un marco de trabajo de protocolos para tunelar nuevos protocolos de aplicación sobre cualquier transporte, cuando tenemos muchos protocolos de aplicación?

Una respuesta es que SOAP está ganando en cuanto a seguridad, enrutamiento y otros aspectos que no pueden ser direccionados con HTTP, o por lo menos no tan robustamente. Un escenario horrible para la futura Web tendría un conjunto de características disponibles para SOAP (seguridad, enrutamiento…), y otro conjunto distinto para HTTP (direccionamiento, métodos conocidos…), y ninguna manera de conseguir lo mejor de ambos.

Una posible solución sería reinventar un protocolo REST (orientado a URI y genérico) en lo alto de SOAP. Lo llamaremos “SHTTP”. Sería una solución potente pero existen muchas dificultades técnicas. Dada una URI en particular, debe existir un y solo un modo de mapear la URI en una representación. Por tanto, se requeriría un nuevo esquema URI. Este nuevo esquema URI sería incompatible con la gran variedad de clientes HTTP que hay desarrollados y podría tardar años en propagarse.

Además, HTTP se usa constantemente para repartir datos binarios, pero SOAP no es bueno en ese aspecto. Los motores HTTP son más eficientes que las herramientas que deben parsear XML. Hay otro problema por el que los mensajes SHTTP no podrían correr en lo alto de SOAP, SOAP suele ir encima de HTTP. Esto es ineficiente, confuso y puede desembocar en agujeros de seguridad donde el mensaje de la capa SHTTP es muy distinto al que envía la capa HTTP.

Pero lo más importante, aunque superemos estas incoherencias sintácticas, no responderíamos a ninguna de las cuestiones que surgieron en la crítica de REST a SOAP. ¿Necesitamos muchos protocolos o sólo uno?, ¿Necesitamos muchos modelos de direccionamiento, o sólo uno?, ¿Podemos conseguir la interoperabilidad con un sistema que usa múltiples protocolos y modelos de direccionamiento?, ¿Es realmente algo idealizado conseguir unificar todo en un simple protocolo y un modelo de direccionamiento?, ¿Debemos exponer servicios o eliminar los límites de los servicios y exponer recursos?, ¿Deben ser prescriptivos o descriptivos los servicios Web estándar?, ¿Se puede manejar la herencia sólo con gateways?, ¿Cambiarían las respuestas a esas

preguntas si integrásemos las aplicaciones dentro de organizaciones en vez de tener límites organizacionales?

Cada parte cree conocer las respuestas. Sólo el tiempo demostrará qué visión es la correcta.

6.1.2 Algunos pensamientos sobre la seguridad de REST-SOAP [15]

Este artículo que exponemos a continuación, hace una comparación en materia de seguridad entre REST y SOAP.

SOAP es una especificación intrínsecamente compleja. Normalmente se sitúa en lo alto de HTTP y por tanto hereda cualquier bug o agujero de seguridad en la implementación de éste. SOAP además esta diseñado para saltarse los firewalls como si fuese HTTP, suele decirse que: “SOAP pasa los firewalls como un cuchillo a través de mantequilla”. Partiendo de la base de que SOAP hace varias cosas mal, la primera de ellas es hacer un túnel en los firewalls usando HTTP.

Filtrar SOAP es algo bastante complicado si nos basamos en el conocimiento de las especificaciones. SOAP usa el mismo puerto que HTTP. El mundo ya ha experimentado los agujeros de seguridad que se producen al correr múltiples servicios sobre el mismo puerto con el protocolo RPC de Microsoft. SOAP usa el método HTTP POST cuando realmente debería usar una extensión de este método. La cabecera de SOAPAction está ahora obsoleta, la única manera de reconocer SOAP es haciendo un parsing XML en el firewall. Suponiendo que hacemos esto, ¿Cómo decidimos si el mensaje debe pasar el firewall? SOAP no tiene ni un modelo de direccionamiento uniforme, ni una estructura interna fiable. A veces hay una cabecera, otras veces no. A veces el cuerpo está codificado como RPC, otras veces no. A veces aparece el nombre de un método, otras veces no. Roy Fielding (uno de los inventores de HTTP) y Jim Whitehead (de WebDAV) ya se plantearon anteriormente este problema.

6.1.2.1 UN EJEMPLO

Digamos que un troyano o un virus están rondando por Internet. El administrador de un sistema puede decidir monitorizar los datos que vienen del exterior. SMTP y HTTP tienen bien definidas las maneras de transportar los datos y usando unos patrones simples, se pueden detectar los virus. Por tanto, es fácil monitorizar todo el tráfico SMTP y HTTP que cruza un firewall.

Es trivial excepto si el tráfico que cruza el firewall está codificado con SOAP. La versión SOAP debe tener un paso de decodificación extra porque SOAP tiene (al menos) tres maneras diferentes de transportar datos. Esto no sería un problema si SOAP usara su propio puerto porque en ese caso sería fácil desactivar el puerto del mismo modo que se hace con el de SSH o FTP. Desafortunadamente SOAP hace un túnel sobre HTTP y sobrecarga este puerto.

Ahora digamos que seis meses antes estuvimos desarrollando una aplicación P2P para compartir datos astronómicos. La llamaremos “starster”. Tenemos tres posibles protocolos para usar. Una opción es usar un protocolo propio en un puerto propio. Esto es correcto desde el punto de vista de la seguridad porque si al administrador no le parece correcto el uso de este programa, puede ir al firewall y cerrar el puerto.

Una segunda opción es usar SOAP. En este caso, starster usará su propio protocolo como una adaptación de SOAP (un conjunto de métodos de este) y SOAP hará un túnel a través de HTTP. Esto significa que el administrador del sistema no podrá saber por defecto si starster se está ejecutando en el sistema. Tampoco podrá evitar el uso de este programa. Necesitaría detectar un espacio de nombres XML particular definido en un documento XML particular y que va encapsulado en un sobre SOAP, que a su vez va encapsulado en un mensaje HTTP sobre TCP.

Una tercera opción es usar HTTP, pero usándolo de acuerdo con la especificación HTTP, sin codificaciones extra. En este caso el tráfico de starter continuaría fluyendo por el firewall porque es indistinguible del tráfico Web. Pero lo más importante es que sería tan seguro como el tráfico Web porque el administrador del sistema podría usar un filtro de tráfico estándar para evitarse los problemas del virus.

Un protocolo de aplicación consiste principalmente en el direccionamiento de los recursos de datos y su manipulación. La manipulación se realiza mediante métodos. En HTTP, algunos métodos están definidos para escribir y modificar datos y otros sólo para leer datos. Esto significa que salvo que se haga un túnel, los firewalls se pueden configurar para que una parte de la red tenga sólo acceso a lectura. En los archivos de “log” se pueden buscar fácilmente las escrituras que puedan contener datos corruptos. El control de acceso de lectura/escritura puede ser separado.

SOAP no hace esta distinción. Cualquier método puede ser de lectura o de escritura. Incluso WSDL no permite hacer esta distinción. De esta manera una potente herramienta de filtrado no sirve de nada. En general, los administradores del sistema pueden leer los ficheros de “log” de una gran variedad de servicios basados en HTTP porque todos son parecidos: GET, PUT, POST, DELETE y URI. Por otra parte, SOAP permite mostrar los mensajes casi de cualquier manera. Está diseñado para tener una forma libre. Los mensajes de diferentes servicios pueden ser totalmente distintos. Un ejemplo trivial, GET/getHistoricalStockQuotes?MSFT le dice a una persona responsable en seguridad: “Ok, es un GET, aunque sea un virus no puede modificar el servidor. Probablemente devuelva algún tipo de reporte del historial de cuota. Si hay un túnel o un bug no es mi problema, será culpa del programador.”

Cuando esta misma persona ve getHistoricalStockQuotes("MSFT") dice: “Probablemente devuelva el fichero de cuota. Pero, ¿Puedo estar seguro de que no va a modificar nada en el servidor? Puede que esté creando un nuevo objeto. De ser así, ¿Quién tiene permiso para crear ese objeto?, ¿Puede un hacker malicioso llenarlo de datos hasta que el servidor desborde la memoria? Mejor voy a leer la documentación para estas cosas, creo que trataré de encontrar al programador para asegurarme de que lo comprendo correctamente.”

Por supuesto que ambos son igual de simples: devuelven un reporte. Pero uno es muy explícito al asegurar que no modificará el estado del servidor, mientras que el otro no.

6.1.2.2 HTTP/REST, LA WEB TIENE UN ESPACIO DE NOMBRES UNIFICADO

Para nuestras intenciones, los protocolos de aplicación son para direccionar y manipular datos y recursos. En la Web, todos los recursos forman parte de un sistema de direccionamiento global, URI. Una de las cosas buenas de usar URI es que proporciona una manera muy tangible para poner los permisos. Por ejemplo, podemos imaginar como se dan o quitan los permisos de un fichero de una orden de compra, y sería equivalente hacerlo con un recurso de orden de compra Web. Esta es una característica Web estándar y tiene sus raíces en las técnicas de permisos que la gente ha usado durante décadas.

La gran diferencia entre un recurso y un fichero es que el recurso es virtual: por ejemplo puede estar representado por una fila en una base de datos. Los permisos los aplicamos a la orden de compra virtual, no a un fichero.

SOAP no ha unificado el concepto de recurso y cada aplicación SOAP se inventa su propio mecanismo de direccionamiento. Al contrario que HTTP, los objetos de datos de SOAP normalmente no están disponibles por medio de una URI. Esto significa que no hay nada a lo que colocar permisos o restringir el acceso. Cada desarrollador de una aplicación tendrá que inventarse su propio mecanismo de direccionamiento e imaginarse como asociar los permisos por sí mismo.

6.1.2.3 LA SEGURIDAD DE SOAP ES ERRÓNEA

SOAP pone gran parte de la responsabilidad sobre seguridad en manos del desarrollador, pero la documentación existente no lo prepara para esta tarea. Consideremos esta cita: “Para la seguridad, usa el protocolo Secure Sockets Layer (SSL) y las técnicas de autenticación Web”. Los defensores de SOAP creen que si tiene algunas características de seguridad, “tiene seguridad”.Si leemos la documentación sobre seguridad en SOAP que tiene Microsoft, no se indica como hacer un servicio seguro. En vez de eso, se describe como limitar el acceso a ciertos dominios. Pero la función de los servicios Web es que podamos poner los servicios en la Web pública de la misma manera que ponemos sitios Web. La documentación menciona los firewalls pero no instruye a los programadores sobre como usarlos correctamente, teniendo un puerto específico para los servicios SOAP.

6.1.2.4 SOAP ES NUEVO Y TODAVÍA NO ESTÁ TESTADO

La gente tiene una gran confianza depositada en el servidor Web Apache. IIS está considerado menos robusto, pero lo suficiente como para tener millones de sitios

funcionando cada día. Consideremos el tiempo que tomó llevar a la seguridad hasta este punto. De momento no podemos confiar en que las herramientas de servicios Web hayan alcanzado este nivel de fiabilidad y seguridad. El mundo de los servicios Web debe tomarse las cosas con más calma y considerar las implicaciones de la seguridad de sus invenciones con mucho más rigor.

6.2 ROBERT McMILLAN

Robert McMillan es un periodista y experto en Servicios Web que escribió varios artículos sobre el debate REST-SOAP. Lo más interesante de este autor es que además de las características técnicas del debate REST-SOAP, se ocupa de otros factores como la publicidad y promoción de las herramientas REST.

6.2.1 REST, sustituto de SOAP-RPC [16]

Pequeño resumen de lo que es REST y su relación con SOAP. Indica que una de las cosas por las que REST no se está extendiendo rápidamente es la falta de promoción.

REST dice que SOAP-RPC no está bien diseñado para compartir datos basados en XML u otros documentos sobre Internet de una manera eficiente porque esos estándares no son más que una repetición de DCOM y CORBA con algunos cambios.

6.2.1.1 EL RESTO DE LA HISTORIA

De acuerdo con los adeptos a REST, la Web ya tiene una arquitectura para sistemas distribuidos que es robusta, segura y ampliamente probada. Está basada en formatos comunes, un estándar de protocolos, y lo más importante, un sistema de nombres estándar: URI.

Específicamente, la arquitectura REST está basada en componentes probados que todavía se usan para crear servicios Web: XML, HTTP y URI. La idea es que en vez de exponer las APIs usando un modelo SOAP-RPC, usemos los métodos que han sido desarrollados para HTTP: GET, POST, DELETE y PUT. Como ejemplo, podemos usarlos para mantener un formato de datos XML organizado mediante URI.

Un sitio Web bastante importante, RESTwiki, describe por qué REST es tan bueno para compartir en Internet los datos y las colecciones de documentos. “No importa que servidor Web tenga, ni el cliente Web que acceda a él, si se ve una URL como http://conveyor.com/RESTwiki/, sabemos que podemos solicitar información usando los métodos HTTP, sin necesitar ninguna coordinación previa. También podremos manipular su contenido con PUT y POST (aunque nos responderán si es posible o no, y las razones de esta decisión)”.

6.2.1.2 EL FUTURO PARA REST Y SOAP-RPC

Una de las razones por las que REST no ha sido ampliamente aceptado todavía es que nadie lo está promocionando. Aunque las ideas de REST llevan un par de años rondando, no existe ni un consorcio REST, ni un estándar REST para desarrollar. Simplemente representa una manera diferente de pensar acerca de los servicios Web, aunque tiene las ventajas de que el funcionamiento, la seguridad y el espacio de nombres llevan probándose en Internet desde hace años.

¿Se podría decir que es REST contra SOAP? No exactamente, dicen los seguidores de REST. SOAP tiene un papel muy importante en el contexto de REST. Algunos adeptos a REST no son muy optimistas sobre su futuro porque SOAP ha llegado a convertirse en sinónimo de RPC, y la gente empieza a asociar servicios Web con SOAP.

6.2.2 Una aproximación a los Servicios Web basada en REST [17]

Entrevista a múltiples personalidades, de la que se obtiene un resumen de lo que es REST. Cabe destacar que al final del artículo se habla del futuro de REST desde un punto de vista de la aceptación comercial que pueda tener. Se discute si es necesario incluir REST en las herramientas de desarrollo para conseguir su consolidación.

¿Es complicado el desarrollo de Servicios Web? Un pequeño grupo de influyentes desarrolladores Web piensa que sí. Estos desarrolladores proponen una nueva aproximación más simple que el modelo SOAP, que está favorecido por desarrolladores de herramientas como BEA Systems, IBM y Microsoft. Esta nueva aproximación arquitectónica se llama Representational State Transfer (REST). Dicen que los resultados son más escalables.

Entre los más destacados partidarios de REST, se encuentran Roy Fielding perteneciente a la fundación Apache y Sam Ruby, un desarrollador senior y gurú de los servicios Web en IBM (aunque IBM no es afín a REST). Los desarrolladores de Amazon y Google han experimentado con REST para crear interfaces a sus populares sitios Web.

6.2.2.1 EL TRABAJO CON REST

REST confía en un solo protocolo de aplicación (HTTP), en URI y en un formato de datos estandarizado a través de XML. Emplea métodos HTTP establecidos como son GET y POST. En vez de crear un estándar, una manera que entiendan las máquinas para descubrir y usar componentes de aplicación en sistemas remotos (la manera que usa SOAP para los servicios Web), los desarrolladores de REST usan URI para crear un terreno común de manera que las aplicaciones puedan usar HTTP y XML para compartir datos. Los desarrolladores de REST usan documentos XML en vez de

llamadas a métodos de aplicación para decirles a los programas distribuidos como usar los datos.

Los adeptos a REST dicen que usando el protocolo SOAP para acceder a las funciones de programas remotos directamente es un fallo del mismo tipo que los problemas de interoperabilidad que sufrían las antiguas arquitecturas de programación distribuidas como DCOM y Common Object Request Broker Architecture (CORBA).

Los problemas de seguridad también afectan a SOAP, dice Mark Baker, un consultor independiente de arquitectura Web y uno de los administradores de un sitio de recursos para desarrolladores. Como los firewall no comprenden el significado de los mensajes de los servicios Web basados en SOAP, nunca dejaran pasar esos mensajes.

Los mensajes REST no tienen este problema, dice Baker, porque solamente usan operaciones especificadas en el estándar HTTP (operaciones bien conocidas por los administradores y las aplicaciones firewall). Los comerciantes Web están solucionando este problema desarrollando estándares de seguridad en los servicios Web y productos, de la misma manera que se desarrollan firewalls y estándares de seguridad para HTTP.

6.2.2.2 REST EL MEJOR

Antes de decidir usar REST para su servicio Web, Thomson consideró usar SOAP. Los desarrolladores eligieron REST porque ofrecía un mejor funcionamiento, fiabilidad y escalabilidad que SOAP.

Usando REST Thomson ahora puede usar documentos de datos de distinta fuente más fácilmente. Thomson dijo: “Antes de usar esta tecnología, teníamos que escribir una solución específica para cada fuente de datos, ahora lo podemos crear rápidamente usando REST”.

La aproximación centrada en documentos de REST se hizo particularmente apropiada cuando los usuarios compartían datos. Creaban documentos XML, y el GTS manejaba el resto: introduciendo documentos XML en el sistema de Thomson, los datos se hacían disponibles. “Aunque el sistema sólo puede manejar un proceso al mismo tiempo, el usuario puede enviar cualquier número de peticiones”. “El GTS maneja las tareas de mantenimiento de recursos, como la prioridad de los trabajos y el balance de cargas, de esta manera el conjunto del sistema se hace eficiente”.

6.2.2.3 UN SOÑADOR REAL

La experiencia de los usuarios de REST ha sido tan prematura como positiva, pero hay una gran carencia de herramientas. Esto es un gran obstáculo para la difusión. Todavía no existen grandes desarrolladores de aplicaciones que hayan adoptado REST, aunque parece que se lo están planteando seriamente. “REST tiene algunas grandes características que estamos examinando.” Dijo David Orchard, director técnico de BEA.

Todavía hace falta que los diseñadores de herramientas adquieran un compromiso con REST para que éste despegue totalmente. Productos como Microsoft's Visual Studio .Net o IBM's WebSphere, automáticamente producen servicios Web basados en SOAP.

“Desde la perspectiva de un producto, REST es casi invisible”, dijo Ronald Schmeltzer, un analista señor. “Si los adeptos a REST quieren triunfar, deben introducirlo en las herramientas que crean o consumen servicios Web.”

Baker no está de acuerdo. Él dice que virtualmente cualquier herramienta HTTP podría servir para desarrollar servicios Web REST. “Hay un montón de herramientas REST disponibles, simplemente que la gente no sabe que existen”, el dijo.

Las mismas herramientas que crean los Java Servlets podría usarse para construir servicios Web basados en REST, dijo Baker. “Siguen las especificaciones HTTP, y por consiguiente, implícitamente están compliendo las restricciones del estilo REST”, el dijo.

BEA sugirió que REST debería coexistir con SOAP algún día porque los desarrolladores buscan múltiples técnicas para los estilos de servicios Web. “A veces hay más de una manera de hacer las cosas”, él dijo.

6.3 ROY HOOBLER

Roy Hoobler es el director de Tecnologías de Internet para la empresa Net@Work y tiene una visión muy simplificada del debate REST-SOAP.

6.3.1 REST puede acabar con SOAP [18]

Entrevista a Roy Hoobler en la que éste expresa su visión peculiar de REST. Desde su punto de vista con REST podemos solicitar información y recibirla, pero ahí es donde termina todo. Dice que de cara a realizar esta función, REST es mucho más sencillo y útil que SOAP, pero no podemos realizar Servicios Web que precisen procesamiento de datos.¿Existe una manera simple de explicar REST?

Sí, viendo el ejemplo de Amazon. Si vamos a construir una aplicación XML, tendremos un fichero XML en una máquina. Sin embargo, en la mayoría de las aplicaciones XML, no tiene por qué ser el caso, porque podemos acceder al archivo XML a través de una URL válida. Por ejemplo, podemos ir a una página Web, conseguir un fichero XML y “parsearlo” en nuestro ordenador.

Si está en una base de datos, debe ser una base de datos local. No podemos conectarnos directamente a la base de datos de Amazon y ellos no van a dejarnos. Por tanto, deben tener un servicio SOAP, o deben realizar una búsqueda a través de HTTP, que es lo que realmente están haciendo. Lo que están haciendo (con REST) es construir un documento XML “al vuelo” y devolver así los datos vía HTTP. Podemos usar esa

información en el sistema, almacenarla y procesarla. Hay muchas cosas que podemos hacer sin necesidad de SOAP ni de programar nada.

¿Es realmente tan simple?

Es un proceso muy simple. Si alguien tiene un archivo XML y nos da la URL, entonces podremos descargar el contenido. La programación queda prácticamente fuera. Alguien puede subir un fichero de texto y yo puedo descargarlo a través del navegador. Es un poco más complicado que eso, pero no demasiado.

SOAP es bastante lento comparado con REST, porque acarrea una mayor carga de comunicación. Cuando usamos REST, estamos cogiendo información como si estuviésemos buscando una página Web de un sitio. La conseguimos rápidamente. Con SOAP, hay mucha más información transaccional detrás de cada operación.

¿Es REST una metodología en vez de una especificación?

Es una técnica. Otros sitios que la han usado mucho son los blogs. Ofrecen lo mismo, pero usan un método llamado RSS (Resource Site Summary). Ofrecen casi lo mismo pero está en formato RDF (Resource Site Summary), que es un formato XML. Por ejemplo, si tenemos una lista de enlaces en nuestro sitio Web que queremos compartir con alguien, todo lo que tenemos que hacer es proporcionarle una URL desde donde puede descargar la información en RDF. Es algo parecido a lo que REST y Amazon hacen. Es una suscripción de servicio barata. No hay que escribir un servicio Web, simplemente vamos allí y cogemos el contenido.

Amazon usa actualmente un Servicio Web al estilo REST para compartir la información del precio de los productos con sus compradores. ¿Qué debería hacer SOAP para realizar la misma función?

Lo primero que debería hacer es implementar un servidor SOAP. Tendrían que desarrollarlo ellos mismos, lo que puede ser algo complicado. Una vez que tienen el servidor SOAP, tendrían que construir clientes SOAP para comunicarse con el servidor. Habría que realizar un gran trabajo de programación, y la mayoría de la gente todavía no ha usado SOAP. Con tecnologías como REST o RSS, toda esa programación no existe, y los servicios Web no precisan de demasiado esfuerzo.

Si es tan simple, ¿Por qué no se ha puesto tan de moda como SOAP?

No es tan potente. Con REST, solamente estás accediendo a contenido. No hay mucho procesamiento. Podemos realizar operaciones mucho más complejas con SOAP. Si Amazon necesitara enviar mucha información, y después hubiese que procesarla, SOAP sería lo más recomendable. REST no ha calado en el mundo de los negocios porque actualmente se necesitan grandes servidores de interacción y REST no es lo suficientemente potente.

Un ejemplo de ello:

Si estamos usando REST, podemos ir a un sitio Web que proporciona una lista de venta de tickets, pero no podemos modificar los tickets. Si estuviésemos usando SOAP,

podríamos manipularlos y enviar el resultado de nuestros cálculos. Digamos que conseguimos los valores de un sitio, y queremos avisar de que son erróneos. Si quisiésemos enviar de vuelta algo que dijese que es erróneo con REST, no podríamos. Con REST podemos solicitar información y recibirla, pero ahí es donde termina todo.

¿Cómo de fácil o difícil resulta aprender a trabajar con REST respecto a SOAP?

Para trabajar con SOAP, necesitamos algún tipo de infraestructura como la de IBM o Microsoft. Otros como Cape Clear ofrecen implementaciones SOAP, pero necesitamos tener instalado todo el Software y conocer la infraestructura. Con REST, para visualizar esa información en una página Web, hace falta conocer XML y XSLT. Muchas plataformas (como Websphere y los servidores de aplicaciones Java) tienen esto integrado o es fácil añadirlo.

Por otro lado, si queremos usar SOAP, tenemos que usar todo el marco de trabajo .NET o usar Websphere Studio. Tendremos que usar una aplicación compleja, que se traduce en una gran inversión de tiempo y dinero.

¿Cómo puede saber una compañía si debería usar REST en vez de SOAP?

Si una compañía está trabajando con datos orientados a contenido, y no ha implementado SOAP, en ese caso REST es una buena opción para empezar a trabajar con XML y RSS. Si ya ha implementado SOAP y la infraestructura está montada, entonces no hay necesidad de usar REST.

6.4 AMIT ASARAVALA

Amit Asaravala es un periodista independiente de San Francisco. Ha sido editor-jefe de una revista centrada en las técnicas Web y fundador de la revista New Architect.

6.4.1 Dando un descanso (REST) a SOAP [19]

En este artículo realiza un resumen de REST a la vez que lo compara con SOAP. Habla de la flexibilidad de la interfaz y de la seguridad. También comenta cuando deja de ser válido el modelo REST, y SOAP comienza a ser una buena opción.

REST es más una vieja filosofía que una nueva tecnología, mientras que SOAP parece que da un salto a la siguiente fase del desarrollo de Internet con nuevas especificaciones. La filosofía de REST expone que los principios y protocolos existentes en la Web son suficientes para crear servicios Web robustos. Esto significa que los desarrolladores que comprendan HTTP y XML pueden empezar a construir servicios Web de una manera correcta, sin necesidad de otras herramientas

6.4.1.1 FLEXIBILIDAD DE LA INTERFAZ

La clave de la metodología de REST es escribir servicios Web usando una interfaz ya conocida y ampliamente usada: URI. Por ejemplo, un servicio de consulta de precios en el que un usuario pregunta por un objeto puede ser tan simple como hacer un script accesible en un servidor Web a través de la siguiente URI: http://www.listadeproductos.com/precio?symbol=QQQ.

Cualquier cliente o aplicación del servidor con soporte HTTP podría llamar a este servicio fácilmente con un comando HTTP GET. Dependiendo de cómo escribió el script el proveedor del servicio, la respuesta HTTP podría ser tan simple como algunas cabeceras estándar y una cadena de texto que contenga el precio actual. O podría ser un documento XML.

El método de la Interfaz tiene beneficios significantes respecto a los servicios basados en SOAP. Cualquier desarrollador puede imaginarse como crear y modificar una URI para acceder a diferentes recursos Web. SOAP, por otra parte, precisa del conocimiento de una nueva especificación XML, y la mayoría de los desarrolladores necesitarán un conjunto de herramientas SOAP para formar las peticiones y “parsear” los resultados.

6.4.1.2 MÁS ÁMPLIO Y ESCLARECEDOR

Otro beneficio de la interfaz REST es que las peticiones y las respuestas pueden ser cortas. SOAP requiere una envoltura XML para cada petición y respuesta. Una vez que se ha declarado el espacio de nombres, la respuesta a una petición en SOAP puede ocupar hasta diez veces más bytes que la misma respuesta en REST.

Los adeptos a SOAP argumentan que toda esta cantidad de bytes es una característica necesaria de las aplicaciones distribuidas. En la práctica, la aplicación de petición y el servicio conocen los tipos de datos antes de tiempo, por tanto, transferir esa información en la petición y en la respuesta es gratuito.

¿Cómo podemos conocer los tipos de datos y su localización dentro de la respuesta antes de tiempo? Al igual que SOAP, REST necesita un documento que resuma los parámetros de entrada y de salida. La parte buena es que REST es suficientemente flexible como para que los desarrolladores puedan escribir ficheros WSDL para sus servicios si fuese necesaria una declaración formal. En caso contrario, la declaración sería tan simple como una página Web (que puede ser leída por los humanos) que diga, “Dé a este servicio una entrada, en el formato q = producto, y le devolverá el precio actual de ese producto como cadena de caracteres“

6.4.1.3 GARANTÍAS DE SEGURIDAD

Probablemente el aspecto más interesente del debate REST contra SOAP es la seguridad. Aunque SOAP insiste en que enviar llamadas a procedimiento remoto a través del puerto estándar HTTP es una buena manera de asegurar que los servicios

Web se pueden soportar a través de los límites organizacionales, los seguidores de REST argumentan que esta práctica es un gran defecto que compromete la seguridad de la red. Las llamadas a REST también van sobre HTTP o HTTPS, pero con REST el administrador (o firewall) puede distinguir la intención de cada mensaje analizando el comando HTTP que se usó en la petición. Por ejemplo, una petición GET siempre puede considerarse segura porque, por definición, no puede modificar ningún dato. Sólo puede solicitarlos.

Por otra parte, una petición SOAP típica usará POST para comunicarse con un servicio dado. Sin mirar dentro del sobre SOAP, una tarea puede ser a la vez un recurso o un consumidor. No existe ninguna manera de saber si la petición sólo quiere solicitar un dato o borrar todas las tablas de una base de datos.

Al igual que para la autenticación y la autorización, SOAP sitúa toda la responsabilidad en las manos del desarrollador de la aplicación. La metodología de REST por el contrario, se da cuenta de que los servidores Web ya tienen soporte para esas tareas. A través del uso de certificados industriales estándar y un sistema común de mantenimiento de identidad (como un servidor LDAP), los desarrolladores pueden hacer que la capa de red realice todo el trabajo pesado.

Esto no sólo es útil para los desarrolladores, hace más fácil la tarea de los administradores, quienes pueden usar algo tan simple como un fichero ACL para mantener sus servicios Web de igual manera que lo harían con otra URI.

6.4.1.4 NO ES VÁLIDO PARA TODO

Para ser justos, REST no es la mejor solución para todos los servicios Web. Los datos que deben mantenerse seguros, no se pueden enviar como parámetros en las URI. Además, grandes cantidades de datos, como los detalles de las órdenes de compra, pueden hacerse rápidamente muy voluminosos e incluso desbordarse dentro de una URI. En esos casos SOAP es una solución bastante consistente. Lo más importante es tomar REST primero y usar REST sólo si es necesario. Esto ayuda a que el desarrollo de aplicaciones sea simple y accesible.

Afortunadamente, la filosofía REST está cuajando entre los desarrolladores de servicios Web. La última versión de la especificación SOAP permitía que ciertos tipos de servicios fuesen expuestos a través de URI (aunque la respuesta siga siendo un mensaje SOAP). De manera similar, los usuarios de la plataforma Microsoft .NET pueden publicar servicios de manera que usan peticiones GET. Todo esto significa un cambio en la forma de pensar a la hora de mejorar el interfaz de los servicios Web.

Los desarrolladores necesitan comprender que enviar y recibir mensajes SOAP no es siempre la mejor manera de comunicar aplicaciones. A veces una simple interfaz REST y texto plano funciona (y salvamos tiempo y dinero en el proceso).

6.5 SAM RUBY

Sam Ruby es un desarrollador de Software que ha hecho grandes aportaciones a los proyectos de Apache Software Foundation y a la estandarización de la Web.

6.5.1 REST + SOAP [20]

Este artículo es un breve resumen de las diferencias entre recursos (REST) y servicios (SOAP). Al final del artículo, expone las carencias de cada uno respecto al otro REST – SOAP = XLink y SOAP – REST = Procedimientos almacenados.

Desde la perspectiva de un protocolo la diferencia (expuesta en los términos más simples), es decidir que parte va dentro de un sobre y cual fuera. Cuando enviamos un cheque a una compañía de tarjetas de crédito, ¿Debemos poner el número de cuenta dentro (SOAP) o fuera (REST) del sobre? Esta diferencia puede parecer un poco exotérica, pero la revolución de la orientación a objetos puede ser expresada en términos similares.

La diferencia más grande entre los dos modelos se encuentra en el nombre del recurso. En REST, el recurso está identificado por medio de Uniform Resource Identifiers (URI). Mientras que SOAP descarta esta posibilidad, la mayoría de los servicios SOAP no se diseñan de esta manera.

REST y SOAP contienen características que la otra carece:

REST – SOAP = XLink

La característica más importante de la que SOAP carece actualmente es la posibilidad de enlazar recursos. SOAP 1.2 hace progresos importantes en esta dirección. Es de esperar que WSDL 1.2 complete este trabajo.

SOAP – REST = Procedimientos Almacenados.Mirando como otros sistemas a gran escala realizan actualizaciones, nos damos cuenta de algunas cosas importantes en las áreas de producción para futuras investigaciones de REST.

Finalmente mencionamos que simplemente porque un servicio use HTTP GET, no significa que sea REST. Si estamos codificando parámetros en la URL, probablemente estemos haciendo uso de una petición RPC a un servicio, y no recuperando la representación de un recurso.

6.6 TIM BRAY

Tim Bray es un desarrollador de Software, fue la persona que más contribuyó a formar los estándares XML y Atom. También es un empresario (cofundó Open Text

Corporation y Antarctica Systems). Actualmente Tim es el director de tecnologías Web de Sun Microsystems.

6.6.1 The SOAP/XML-RPC/REST SAGA [21]

Artículo en el que comienza dando unas nociones de los métodos GET y POST para después pasar a explicar con un ejemplo las discrepancias entre REST y SOAP a la hora de su puesta a punto. Tim Bray asocia GET con REST y POST con SOAP.

6.6.1.1 MANERAS DE HABLAR A UN SERVIDOR WEB

Un fragmento de Software que quiere hablarle a un servidor Web (un navegador por ejemplo, aunque hay muchos otros), generalmente usa el protocolo HTTP, que soporta todas las clases de transacciones, las más usadas son GET y POST.

GET es simple: enviamos una petición codificada en una URI al servidor, y obtenemos de vuelta del servidor un paquete de información. Esto es lo que ocurre cuando hacemos clic en un hiperlink; nada puede ser más fácil, la gran mayoría de las transacciones Web son GET. Hay más reglas que acompañan a GET, no está bien usarlo para hacer una compra o cualquier cosa que haga cambiar el estado. Es sólo para solicitar información.

Cuando usamos POST, contactamos con el servidor y enviamos un paquete de información, no una URI, y recibimos otro paquete de información. Deberíamos usar POST si queremos hacer algo más que solicitar información, por ejemplo comprar algo. La mayoría de las veces cuando rellenamos un formulario en un sitio Web y presionamos enviar, se está usando un POST.

Todo esto no tiene muchas complicaciones si consideramos que la Web son navegadores y páginas. Pero mucha gente quiere usar la Web para más; para sindicar blogs, ejecutar motores de búsqueda, incluso para programas B2B a gran escala.

¿Cómo hacemos que esto encaje en el mundo GET/POST? Hacemos notar que normalmente enviamos desde el servidor XML orientado a una máquina antes que HTML orientado a humanos. Si hacemos una petición con un POST, el paquete de información que enviamos normalmente es XML también.

6.6.1.2 POST Y GET ¿IMPORTA ESO?

Realmente si. Lo primero de todo, si vamos a hacer algo que necesita algo más que solicitar información, debemos usar POST. Si por el contrario solo vamos a solicitar información, debemos usar GET, incluso si pudiésemos usar POST.

La razón de usar este método es que el parámetro de entrada de GET es una URI, así de simple, una maravillosa cadena de caracteres puede ser usada para direccional cualquier cosa en la Web, lo que más o menos es todo en estos días. Esto significa que podemos

mandar un e-mail a esa URI, o llevarla a un motor de búsqueda, o almacenarla en el bookmark, o hacer una serie de cosas que probablemente todavía no se hayan inventado.

Esto también significa que los elementos como caches y proxies pueden realizar su trabajo más rápidamente y por consiguiente hacer la Web más rápida.

6.6.1.3 REST

A la gente (como el W3C TAG) que trata de promover el uso de GET, se les dice que son discípulos de REST. REST es un acrónimo inventado por Roy Fielding que forma parte de la fundación Apache y fue uno de los autores de la especificación URI. Lo inventó para su tesis en la que trataba de formalizar la manera de trabajar de la Web.

Por otra parte, hay bastante gente acostumbrada a pensar en forma de complicadas estructuras de datos y complejas APIs. Esta gente tiende a pensar que GET es demasiado simple, inflexible y poco sofisticado. Están en lo cierto puesto que en los casos en los que solicitamos información es cuando entra en juego la ventaja de nombrar con URI, lo que hace que las transacciones con GET sean tan sumamente simples.

La gente que no está de acuerdo tiende a usar POST; prefieren codificar un paquete que contiene argumentos con una complicada API, en algunos casos como complicadas estructuras de datos, enviándolas y recibiendo de nuevo más estructuras de vuelta. Esta visión está fuera de la semántica Web en términos de ser una realidad práctica y útil.El conflicto entre REST y SOAP/XML-RPC fue sacado a la luz por Paul Prescod, cuando escribió acerca del camino que estaba tomando Google. Fue una primera vista de los temas a tratar.

6.6.1.4 SOAP y XML-RPC

Hay dos niveles de protocolos de bajo nivel que podemos usar para enviar (POST), SOAP y XML-RPC. SOAP, que creció del trabajo de Dave Winer y Microsoft, es bastante complejo y sobre-equipado para lo que debería ser una simple tarea, aunque también existen buenas implementaciones. XML-RPC desarrollado casi entero por Dave, es por el contrario demasiado simple y poco equipado, incluso para lo que debería ser un trabajo simple, aunque también existen buenas implementaciones.

6.6.1.5 EL CASO DE TECHNORATI

Technorati es un sitio Web que maneja cientos de miles de blogs. La mayoría de los autores lo visitan regularmente para saber cuantos enlaces les apuntan. Dave Sifry de Technorati, inteligentemente, llegó a la conclusión de que los resultados deberían estar

disponibles en XML, de manera que cualquiera que quisiera, pudiese conseguir la información fácilmente. La manera que propuso fue puramente al estilo REST, indicó como construir una URI para encontrar quién estaba apuntando y saber a qué apuntaba. Él simplemente documentó el XML que devolvería cuando se realiza un GET.

Dave Winer señaló que sería más fácil para los programadores con herramientas XML-RPC o SOAP conseguir esto vía POST si la interfaz fuese SOAP o XML-RPC. También señaló que es realmente poco útil que la URI tuviese que incluir un “appkey” (es una marca que da acceso a usar el servicio. Hay un límite de veces que se puede usar al día, excepto si pagamos dinero).

Realmente la postura de Dave Winer no es buena del todo (para no crear confusión entre ambos Daves, les llamaremos DW y DS). Como primer punto diremos que, esto es una aplicación al más puro estilo dame-algo-de-información, y construir las URI genera un poco más de trabajo, pero conseguimos que los resultados de Technorati sean ciudadanos de primera clase dentro de la Web y estén representados por cadenas cortas.Obviamente si queremos construir una aplicación para enviar dinero a DS por usar su servicio, querremos enviar vía POST XML-RPC o algo equivalente.

El segundo punto de DW tampoco es totalmente correcto, aunque es cierto que si publicamos una URI con el appkey en ella, entonces cualquiera que consiga entrar y usarlo, estará haciendo uso de nuestra cuenta. No podemos saber si las cuentas basadas en appkey encajan bien en la arquitectura Web, es algo que deberá investigarse.Hay otros métodos para realizar cuentas en los sitios Web; desafortunadamente para DS, la mayoría de ellas necesitan más trabajo para configurarlas que la aproximación por appkey.

¿Compensa usar la potencia de nombrar todo con URIs teniendo en cuenta los inconvenientes de tener que introducir complejas peticiones en ellas? ¿Compensa la opción de empaquetar las peticiones en XML con el inconveniente de perder la potencia de nombrado?

6.7 BENJAMIN CARLYLE

Benjamin Carlyle es un desarrollador de Software. Este autor se ha mostrado muy activo a lo largo del debate REST-SOAP.

6.7.1 REST vs Orientación a Objetos [22]

Este artículo no compara REST directamente con SOAP sino con la Orientación a Objetos (OO). Explica los comienzos y orígenes de REST y OO. En cuanto al tema concreto de REST, este autor tiene una visión un poco particular de REST en términos de propiedades.

Las URIs son muy parecidas a los OIDs (punteros, referencias, o similares). Son cosas que se pueden dereferenciar para conseguir el recurso que buscamos, por tanto, no son

comparables con las ideas de espacio de nombres global o variable local. Esto es una importante distinción de la que todavía no sabemos sus repercusiones.

Estamos en un estado en el que podemos comparar REST y la Orientación de Objetos desde un punto de vista práctico. Ahora, cuando la mayoría de la gente habla sobre REST, se están refiriendo a su uso como la mejor guía de diseño práctica para la Web. Cuando nosotros hablamos sobre ello, lo vemos desde el punto de vista de un desarrollador de software modular y distribuido. Hablamos de servicios Web y no del uso de HTML y los navegadores Web. Hablamos de diseño de software, no de diseño de sitios Web.

6.7.1.1 SIMILITUDES

Desde nuestra perspectiva, los conceptos de Orientación a Objetos (OO) y REST son comparables. Ambos buscan identificar “cosas” que corresponden a algo que conocemos y con lo que interactuamos. En OO lo llamamos objeto. En REST lo llamamos recurso. OO y REST permiten algunas formas de abstracción. Podemos reemplazar un objeto por otro de la misma clase o del mismo tipo sin cambiar la manera en que el código del cliente interactúa con el objeto. El tipo es una abstracción común que representa cualquier objeto que encaje igual de bien. Podemos reemplazar un recurso por otro sin cambiar la manera en que los clientes interactúan con él. Los recursos son conceptos ligeramente menos pesados que los objetos, cuando hablamos de recursos normalmente necesitamos mencionar el espacio URI (el espacio de nombres de los recursos). Los clientes pueden interactuar con un nuevo software de servidor a través de sus recursos de la misma manera que interactuaban con el viejo software del servidor. Los recursos que se presentan representan a ambos igual de bien.

6.7.1.2 DIFERENCIAS

La principal diferencia es el enfoque. Los objetos están enfocados en el tipo como un conjunto de operaciones que podemos realizar a un objeto en particular. Por otra parte REST dice que el conjunto de operaciones que podemos realizar a los recursos debe ser casi completamente uniforme. En vez de definir nuevas operaciones, REST enfatiza la creación y nombrado de nuevos recursos. Tanto como la limitación de verbos, REST busca reducir el número de tipos de contenido que entran en juego. Podemos dibujar REST como un triángulo con tres vértices que representan “nombres”, “verbos” y “tipos de contenido”. REST busca inclinar la balanza desde los verbos y tipos de contenido hacia el vértice de nombres. La orientación a objetos esta equilibrada en algún lugar entre los verbos (funciones) y los tipos de contenido (tipos y lista de parámetros). Cuando comprendamos los extremos de este triángulo, aprenderemos más sobre como inclinar la balanza para un problema en particular.

En OO los nombres de los objetos son siempre relativos a objeto actual o al espacio de nombres global. Normalmente vemos todo el acceso restringido a esto->algo,

parámetro->algo o algunacosa->algo, donde algo es normalmente un verbo. Es difícil navegar más profundo en este nivel porque la manera en que OO mantiene la abstracción está demasiado oculta al conocimiento de otros objetos. En vez de eso, el diseño de OO normalmente proporciona una llamada que puede referenciar el estado o llamadas a funciones de sus propios objetos.

REST dice que el espacio de nombres debería ser lo más importante. Cada objeto que pueda contactar con otro objeto debe tener un nombre. No cualquier nombre, un nombre globalmente accesible. Si llevamos esto al extremo, cada objeto que pueda ser accesible desde otro objeto debe ser también accesible desde cualquier lugar del mundo por un identificador único y global:

En principio, cada objeto que alguien pueda querer o necesitar para citarlo debe tener una dirección que no conduzca a ambigüedades.

Douglas Engelbart en 1991 creó un documento sobre el nombrado, Berners-Lee escribió: “Este es probablemente el aspecto más crucial del diseño y estandarización en un sistema abierto de hipertexto. Concierne a la sintaxis del nombre que un documento o una parte de éste sea referenciada desde cualquier parte del mundo.”

REST proporciona cada abstracción por medio de su espacio de nombres jerárquico en vez de intentar esconder el espacio de nombres. Desde el momento en que todos los objetos accesibles participan en esta interfaz simple, la línea entre los objetos está borrosa. OO está fija al concepto de un objeto detrás de una abstracción, pero REST permite desacoplar el conocimiento incluso sobre el objeto que está proporcionando el servicio que pedimos.

6.7.1.3 HISTORIA

La historia que vamos a describir puede decirse que está fundamentada en rumores más que explicar exactamente como emergió cronológicamente cada aspecto. Podemos seguir la ruta de la historia de la OO desde la práctica de la programación estructurada. En la programa programación estructurada usamos muchos bucles “for” y “while”. Atajamos un problema pensando en los pasos que debemos seguir para ejecutar la solución. En aquellos tiempos era difícil mantener estructuras de datos, porque a menudo significaba tener que mantener grandes cantidades de código base. Una implementación con listas enlazadas necesitaba insertar el código de la operación muchas veces, de manera que cuando cambiábamos de lista simplemente enlazadas a doblemente enlazadas era difícil asegurarnos de que todo el código seguía funcionando correctamente. Esto necesitó de la abstracción para conducirnos a la noción de Tipos de datos abstractos (ADTs).

ADT fue un gran hito. Definiendo un conjunto de operaciones legales en una estructura de datos y manteniendo todo el código en su lugar, podíamos reducir los costes de mantenimiento y manejar la complejidad. ADT se convirtió en una abstracción que

podía representar diferentes implementaciones igual de bien. Las ventajas fueron tan importantes, que los detalles de las implementaciones subyacentes como las variables miembro se escondieron al código del cliente. Evitar fallos en la disciplina de la programación fue un gran enfoque.

La orientación a objetos se presenta cuado decimos “Esto funciona tan bien, ¿Por qué no lo aplicamos a estos conceptos?” En vez de aplicar la técnica solo a las estructuras de datos, encontramos que podemos aplicarlo siempre que necesitemos abstracción. Podríamos aplicarlo a algoritmos o a cualquier cosa conceptualmente abstracta. Desarrollamos patrones de diseño con intención de explicar a los demás como usar objetos para resolver problemas.

6.7.1.4 LA HISTORIA DE REST

REST tiene una historia obvia en la red, donde la abstracción es un concepto fundamental. Los recursos de la Web operan a través de protocolos y otros mecanismos que nos fuerzan a esconder la implementación de un objeto de la de otro. Las semillas de REST se encuentran en el software “puro” también.Veamos los Java Beans. Las propiedades de los Bean son las siguientes:

1. Cada clase Java Bean debe implementar el interfaz java.io.Serializable2. No debe haber constructores sin parámetros3. Las propiedades deben ser accedidas usando los métodos get y set.4. Debe contener los métodos manejadores de eventos requeridos

Esto es un paso significativo desde un modelo orientado a objetos hasta lo que es REST. Dejaremos de lado la implementación de serializable que permite almacenar, transmitir y desempaquetar una representación en el otro extremo. También dejaremos de lado el constructor por defecto. Lo que consideraremos realmente importante es el uso de las propiedades, o como podríamos llamarlas: Recursos.

Es mucho más fácil tratar con un conjunto (“real” o de otro tipo) de propiedades que tratar con llamadas a funciones. Los seres humanos encontrarán más fácil tratar con esos objetos. Incrementando la presencia de objetos en el espacio de nombres y definiendo un conjunto de operaciones que pueden ser usadas con cada elemento presente en ese espacio de nombre, conseguimos un aumento de la facilidad en el trato con cada elemento. No perdemos ninguna abstracción de las que ganamos al cambiar a ADT, en primer lugar porque ahora esas propiedades no están revelando la implementación interna de nuestro objeto. Están formando parte de la interfaz. Cuando configuramos esas propiedades o las conseguimos, el código todavía se esconde a la hora de hacer lo que los objetos eligen. El conjunto de propiedades puede representar diferentes tipos de objetos igual de bien.

Esto es un ejemplo del triángulo que forman los verbos y tipos de contenidos para ir hacia los nombres. Parece ser más importante conocer como se llama algo que el tipo de datos que es. Este resultado no es obvio desde los primeros principios.

6.7.1.5 ¿CÓMO HACER QUE NUESTRO SOFTWARE SE ACERQUE MÁS A REST?

Trataremos de exponer nuestras funciones como propiedades o sub-objetos en vez de funciones, exponiendo un simple conjunto de funciones en esas propiedades. Una buena práctica de REST actualmente significa que usar GET, PUT y DELETE es la mayor parte de lo que necesitamos. Deberíamos usar POST como una operación “Crear y PUT”. Trataremos de dar nombres globalmente accesibles a los recursos. La teoría es que otros objetos sólo accederán a ellos si les damos un hiperlink, de manera que la privacidad no sea un problema. Usar tipos que sean lo más simple y uniforme posible.

Cualquier código que acceda a este nombre, verbo y tipo de contenido operará simplemente usando hiperlinks. Podemos elegir abrir el acceso a otros espacios URI, como hace HTTP y los esquemas de ficheros. De esta manera podemos hacer hiperlinks desde y hacia esos espacios sin alterar el significado de código del cliente.

6.8 Disenchanted dictionary

Disenchanted dictionary es una página Web donde los autores cuelgan artículos de manera anónima. En este sitio se pueden encontrar artículos relacionados con el mundo de los Servicios Web.

6.8.1 REST [23]

Este artículo realiza una comparación entre REST y SOAP en cuanto a flexibilidad y complejidad.

Cualquier página Web a la que miremos, está representando algún dato. Esto significa un estado específico, y se transfiere al navegador cuando hacemos una petición de un recurso disponible a una determinada dirección (algo como http://www.disenchanted.com/dis/lookup?node=1837). REST es una manera de describir como cada petición de una página Web en Internet funciona, pero también es una manera de construir servicios Web.REST compite en el nivel más alto con SOAP, un protocolo de llamada a procedimiento remoto que trata los servicios remotos como funciones que se invocan con argumentos. REST puede llegar a hacer lo mismo que SOAP, pero siguiendo un modelo diferente. En vez de tratar los servicios remotos como programas que corren y necesitan argumentos, REST solo conoce los recursos por su URI. La diferencia con la que cada modelo trata los recursos remotos implica algunas ventajas para REST.Con SOAP, se espera que un programa corra en una máquina remota cada vez que se llama a una función, lo que se devuelve se crea momentos antes de usarse. REST no asume eso, sólo conoce que hay algún dato en una dirección. La dirección apunta al tipo de datos que quiere y al estado en el que debe estar. Es como la diferencia entre pedir a una secretaria que calcule una factura (SOAP) o pedirle simplemente que la devuelva (REST).

Independientemente de la manera en que formulamos la petición a la secretaria, obtendremos los mismos datos. La cuestión es determinar cuanto trabajo está implicado para la pobre secretaria. ¿Tendrá que coger la calculadora y hacer uso de las matemáticas o simplemente abrirá un fichero y cogerá un papel que fue escrito días o semanas antes?

Esta es la ventaja que tiene REST sobre SOAP. La URI que copiamos en el navegador Web (u otra aplicación) define exactamente lo que queremos y el estado en que lo queremos (como puede ser el tiempo en Nueva York el dia 1 de Abril de 1999). Si para darnos este dato el servidor tiene que ejecutar un programa que genere la información “al vuelo”, o simplemente la recupera de un fichero creado años antes, es algo que no inmiscuye ni la red ni a la persona que se ocupa de configurar el servidor. Con SOAP esto no es posible, y probablemente nunca lo será, porque el paquete SOAP es más complejo. SOAP hace difícil saber si un dato ha sido calculado antes cuando ejecutamos un simple programa de recogida de datos.

REST es más simple, pero depende de HTTP como protocolo que envía peticiones en una dirección y datos en la otra. Esto podría ser una ventaja porque HTTP tiene un grupo de funciones diseñadas y testadas, como la autenticación y el mantenimiento de recursos, mientras que cualquier cosa construida en SOAP necesita reinventar todo eso.

También puede ser una desventaja. SOAP puede hacer un túnel sobre cualquier protocolo, no solo HTTP (podemos enviar paquetes SOAP por e-mail, por ejemplo, si el retraso no es un problema en nuestra aplicación). Con SOAP, la petición puede ser más sofisticada; por ejemplo, puede codificar tipos de datos.

6.9 Conclusiones

En este capítulo se ha dado una visión general del debate que ha existido en la Web entorno a la comparación entre REST y SOAP. Se han expuesto los artículos más relevantes que se han escrito hasta el momento. En el siguiente capítulo se comentarán algunos de los Servicios Web que están actualmente funcionando de acuerdo al modelo de arquitectura REST.

7 IMPLEMENTACIONES

En este capítulo se comentan algunos de los Servicios Web que están actualmente funcionando de acuerdo al modelo de arquitectura REST. Además se proporciona un ejemplo para comprender mejor el diseño de un Servicio Web y se incluye un artículo que enumera los principales errores de implementación.

7.1 Implementaciones REST en la Web

Actualmente ya hay implementados algunos servicios Web que tienen un diseño al estilo REST (creando sus propias API), como ejemplos notables están eBay, Amazon y Blogger. Aunque la realidad es que estas implementaciones nunca han sido catalogadas totalmente como REST, porque analizándolas exhaustivamente, algunas violan las restricciones esenciales de REST según las necesidades que tengan.

Uno de los pasos más grandes que se han dado es la creación de Restlet, una API que nos permite implementar los Servlets de Java siguiendo el estilo REST. La principal ventaja de Restlets es que permite programar Servicios Web de carácter general, no está diseñado para un Servicio en particular (como ocurre con las API de Amazon o eBay).

A continuación se comentan más profundamente estas implementaciones.

7.1.1 Amazon

Amazon es una empresa muy potente en el campo de la venta online. Se podría decir que fue uno de los pioneros en el uso de Servicios Web REST.

Su funcionamiento se basa en la esencia de REST. Posee una base de datos con todos los detalles de los productos que vende. Cuando un usuario quiere realizar una búsqueda o acceder a la información de determinados productos en particular, accede directamente a los recursos solicitados y no a métodos remotos.

Se puede ver la API asociada a Amazon.com (disponible en associates.amazon.com). Permite hacer una petición asociada a la base de datos de Amazon.com e integrar los resultados obtenidos en el sitio. La petición es un HTTP GET normal y el resultado es un documento XML

El hecho de que una empresa tan importante se haya decantado por el uso de REST apoyó bastante al despegue de esta tecnología. El nombre de Amazon ha estado bastante ligado al debate sobre REST que existe en la red. Muchos de los autores que se han expuesto lo han usado como ejemplo en sus artículos.

Sin embargo, existe un aspecto que ha sido bastante criticado sobre la API de Amazon. Solamente usa uno de los cuatro métodos HTTP, que es GET. Por lo que no se puede decir que use todo el potencial de REST. La crítica a Amazon [12] alega que cuando Amazon necesite realizar Servicios Web más complejos, no le bastará con usar el resto de métodos, sino que necesitará migrar a SOAP.

7.1.2 eBay

eBay es una famosa empresa dedicada a la venta y subasta de productos en la red. Es uno de los “gigantes” de la Web.

En 2004 eBay sacó a la luz una API basada en REST a disposición de los clientes [24]. La interfaz de programación de aplicación REST (REST API) de eBay es una manera sencilla de integrar la funcionalidad de eBay en una página Web o una aplicación. La API REST permite usar una llamada, GetSearchResult, para obtener información sobre los productos de eBay. La información devuelta por la llamada a GetSearchResult está en formato XML. Además de usar GetSearchResult para obtener información sobre los productos de eBay, se permite el procesamiento que transforma los resultados de la búsqueda usando ficheros XSL que se suban. Se accede al fichero XSL subido usando un link de la página central de desarrolladores REST (http://developer.ebay.com/rest).

Aquí se expone un ejemplo de llamada que usa la API REST. Los parámetros usados como CallName, son parámetros de entrada específicos de la API REST

http://rest.api.ebay.com/restapi?CallName=GetSearchResults&RequestToken =xyz123&RequestUserId=ebayuser&Query=toy%20boat&Schema=1

Como se puede observar, esta API viola una de las restricciones de REST. eBay nos ofrece GetSearchResult que es un método remoto al que se le pasan argumentos. Esta práctica va en contra de REST. eBay debería proporcionar recursos a los que acceder y no métodos. Dicho de otra manera, debería ofrecer nombres y no verbos.

7.1.3 Restlets

Restlets es una API desarrollada en 2006 cuya misión es acercar la simplicidad y eficiencia de REST a los desarrolladores Java. Actualmente se encuentra en la versión 1.0 beta 14.

El autor de Restlets es Jérôme Louvel. A continuación se expone un fragmento de un artículo en el cual explica qué es Restlets [26].

Cuando empezamos el desarrollo de un sitio Web, queremos cumplir con el estilo de arquitectura REST lo máximo posible. Después de investigar bastante, nos dimos cuenta de que existía la carencia de un marco de trabajo REST para Java. El único proyecto que se había llevado a cabo era 1060 NetKernel desarrollado por 1060 Research pero contenía demasiadas características para nuestras necesidades y no soportaba correctamente los conceptos de REST.

Esto nos llevó a desarrollar nuestro propio marco de trabajo REST encima de la API Servlet. Llegó a un punto en el que la API Servlet estaba completamente oculta. Hicimos una separación entre la implementación del protocolo HTTP y el soporte para la API Servlet. Al final, estábamos preparados para desarrollar el primer conector Restlet, un conector de servidor HTTP que permitía llamadas uniformes REST.

También queríamos deshacernos de la separación que existe en Java entre la vista de la parte del cliente y la del servidor. En la Web actual no necesitamos hacer esas diferencias. Nadie va a actuar al mismo tiempo como cliente y servidor Web. En REST, cada componente puede tener tantos conectores de cliente y servidor como necesite, por lo que simplemente desarrollamos un conector HTTP basado en la clase URLConnection. Por supuesto, se pueden proporcionar otras implementaciones, como una basada en Yakarta Commons HTTP Client.

Después de varios intentos, estuvo claro que sería beneficioso para los desarrolladores separar el proyecto Restlet en dos partes.

La primera parte es un conjunto genérico de interfaces llamada Restlet API, que incluye algunas clases de ayuda y mecanismos para registrar una implementación Restlet.

La segunda parte es una referencia a la implementación, llamada Noelios Restlet Engine, que incluye un conector de servidor HTTP, conectores de clientes HTTP, JDBC y SMTP, un conjunto de representaciones basadas en cadenas, ficheros, streams, channels o FreeMarker, y un directorio Restlet que puede servir ficheros estáticos de un árbol de directorios con negociación automática del contenido basada en las extensiones de los ficheros.

Los desarrolladores de Java necesitan empezar a pensar a la manera de REST cuando desarrollen nuevos Servicios Web. EL proyecto Restlets proporciona una manera simple pero a la vez sólida para que comiencen con buen pie en la Web 2.0.

7.2 Ejemplo de uso de REST

A continuación se va a exponer un ejemplo de Roger L. Costello [9] para explicar el uso de REST.

Parts Depot, Inc (una compañía ficticia) ha desarrollado un Servicios Web para permitir a sus clientes;

Conseguir una lista de partes (productos) Conseguir información detallada de una parte en particular Emitir una orden de compra (Purchase Order, PO)

Estudiaremos como se implementa cada una de esas partes en REST.

7.2.1 Conseguir una lista de las partes

El servicio Web hace disponible una URL para un recurso de lista de partes. Por ejemplo, un cliente podría usar esta URL para conseguir la lista de partes:

http://www.parts-depot.com/parts

Debemos darnos cuenta de que la manera en que el servicio Web genera la lista de partes es completamente transparente al cliente. Todos los clientes conocen que si acceden a esa URL, entonces se les devuelve un documento que contiene la lista de las partes. Como la implementación es transparente a los usuarios, Parts Depot es libre de modificar la implementación subyacente de este recurso sin que esto tenga un impacto en los clientes.

Este es el documento que recibe el cliente:

<?xml version="1.0"?>

<p:Parts xmlns:p="http://www.parts-depot.com" xmlns:xlink="http://www.w3.org/1999/xlink"> <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/> <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/> <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/> <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/></p:Parts>

Estamos asumiendo que por medio de la negociación, el servicio ha determinado que el cliente quiere una representación en XML (por un proceso máquina-máquina). Debemos darnos cuenta de que la lista de partes contiene links para conseguir información detallada sobre cada parte. Esto es una característica clave de REST. El cliente se transfiere de un estado a otro examinando y eligiendo de entre las URL alternativas que se entregan en el documento que se ha obtenido como respuesta.

7.2.2 Conseguir datos detallados de una parte

El servicio Web hace disponible una URL para cada recurso parte. Un cliente solicita por ejemplo la parte 00345 de la siguiente manera:

http://www.parts-depot.com/parts/00345

El documento que recibe el cliente como respuesta a esa petición, es el siguiente:

<?xml version="1.0"?><p:Part xmlns:p="http://www.parts-depot.com" xmlns:xlink="http://www.w3.org/1999/xlink"> <Part-ID>00345</Part-ID> <Name>Widget-A</Name> <Description>This part is used within the frap assembly</Description> <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/> <UnitCost currency="USD">0.10</UnitCost> <Quantity>10</Quantity></p:Part>

De nuevo, debemos observar cómo estos datos enlazan a más datos. La especificación para estos datos puede encontrarse a través del hiperlink. Cada documento de respuesta permite al cliente seguir explorando para conseguir información más detallada.

7.2.3 Emitir una PO (orden de compra)

El servicio Web hace disponible una URL para emitir una PO. El cliente crea un documento de instancia de PO que es conforme al esquema de PO que Parts Depot ha diseñado (y ha hecho público en un documento WSDL). El cliente envía Po.xml como la carga de un mensaje HTTP POST.

El servicio de PO responde al HTTP POST con una URL a la PO enviada. Así, el cliente puede recuperar la PO en cualquier momento posterior (para actualizarla o editarla). La PO se ha convertido en un fragmento de información que se comparte entre el cliente y el servidor. A la información compartida (PO), el servidor le asigna una dirección (URL), y se expone como un servicio Web.

7.3 Errores comunes a la hora de diseñar con REST

En este apartado se incluye un artículo de Paul Prescod [10] en el que se enumeran los principales errores a la hora de implementar Servicios Web al estilo REST.

Cuando se diseña el primer sistema REST, hay varios errores que la gente comete a menudo. En este artículo se van a resumir para que la gente pueda evitarlos.

1. Usar HTTP no es suficiente. Algunas personas usan HTTP en un servicio Web sin SOAP o XML-RPC y hacen el equivalente lógico de SOAP o XML-RPC. Si vamos a usar mal HTTP deberíamos dejarlo y hacerlo de una manera estándar.

2. No sobreusar POST. POST es en algún sentido el método más flexible de HTTP. Tiene una definición más débil que los otros métodos y soporta el envío y recepción de información al mismo tiempo. Por tanto, hay una tendencia a querer usar POST para todo. En el primer servicio Web que creemos, sólo deberíamos usar POST cuando estemos creando una nueva URI. Cuando vayamos cogiendo soltura, puede que decidamos usar POST para otra clase de mutaciones en un recurso. Una regla útil es preguntarnos si estamos usando POST para hacer algo que realmente es un GET, DELETE o PUT, o puede ser descompuesto como una combinación de esos métodos.

3. No depender de la estructura interna de las URI. Algunas personas piensan en el diseño de REST en términos de configuración de un conjunto de URIs. “Pondré las ordenes de compra en /compras y les daré a todas ellas números como /compras/12132 y los documentos de clientes estarán en /clientes…” Esto puede ser una manera útil de pensar si estamos haciendo un borrador, pero no debería ser nuestra interfaz pública final para el servicio. De acuerdo con los principios de la arquitectura Web, la mayoría de las URIs son opacas para el software del cliente la mayor parte del tiempo. En otras palabras, nuestra API pública no debería depender de la estructura de nuestras URIs. En vez de eso, debería haber un único fichero XML que apunte a los componentes de nuestro servicio. Esos componentes deberían tener hiperlinks que apunten a otros componentes y así sucesivamente. Por tanto, podemos introducir a la gente a

nuestro servicio con una única URI y podemos distribuir los actuales componentes a través de ordenadores y dominios siempre que queramos. Una regla es que los clientes sólo “fabrican” URIs cuando están construyendo peticiones para buscar datos (usando cadenas de caracteres para formarla). Esas peticiones devuelven referencias a objetos con URIs opacas.

4. No poner acciones en URIs. Esto surge naturalmente del punto anterior. Un abuso de las URIs es tener cadenas de búsqueda como "someuri?action=delete". Primeramente, estaríamos usando GET para realizar una operación que no es segura. Segundo, no hay una relación formal entre esta “acción URI” y el objeto “URI”. También hay que resaltar que nuestra decisión de convenir “action=” es algo específico para nuestra aplicación. REST trata de conducir fuera del protocolo todas las “convenciones de aplicación” que pueda.

5. Los servicios son raramente recursos. En el diseño REST, un servicio que nos proporcione una cuota que indica el stock de unos determinados artículos no es muy interesente. En vez de eso, en un diseño REST deberíamos tener recursos “stock” y un servicio sería un índice de los recursos “stock”.

6. Las sesiones son irrelevantes. No debería haber necesidad alguna de que un cliente haga el proceso de “login” o comience una conexión. La autenticación HTTP se realiza automáticamente en cada mensaje. Las aplicaciones cliente son consumidoras de recursos, no de servicios. Por tanto, no hay nada sobre lo que realizar el proceso de “login”. Si estamos reservando un billete de avión en un servicio Web REST, no creamos una nueva conexión de sesión para el servicio. Más bien preguntamos por el objeto creador del itinerario para crear un nuevo itinerario. Podemos comenzar rellenando un formulario y después conseguir algunos componentes totalmente diferentes de alguna parte de la red para seguir rellenando otros formularios. No hay sesión, por lo que no existen problemas de migración del estado de la sesión entre clientes, Tampoco hay problemas de “afinidad de sesión” en el servidor.

7. No inventar identificadores de objetos propietarios. Debemos usar URIs. Las URIs son importantes porque siempre podemos asociar información con ellas de dos maneras. El método más simple es poner datos en un servidor de manera que la URI pueda ser dereferenciada para conseguir los datos. Debemos darnos cuenta de que esta técnica sólo funciona con URIs que puedan ser derreferenciadas, por lo que esas URIs (HTTP URIs) son bastante más recomendables que el uso de URIs basadas en URN o UUID. Otra manera es usar RDF y otras técnicas para que nos permitan proyectar metadatos en una URI que puede que no esté bajo nuestro control. Si usamos la sintaxis URI con UUID o algo parecido, entonces solamente obtendremos la mitad de los beneficios de las URIs. Tendremos una sintaxis estandarizada pero tendremos una capacidad de dereferenciar que no está estandarizada. Si usamos URIs HTTP obtendremos la otra mitad de los beneficios porque obtendremos un mecanismo estandarizado para dereferenciar.

8. No debemos preocuparnos por la independencia del protocolo. Sólo existe un protocolo que soporta una semántica correcta para la manipulación de recursos. Si en el futuro surge otro, será fácil mantener el mismo diseño y simplemente soportar una interfaz de protocolo distinta. Por otra parte, lo que normalmente entiende la gente por “independencia del protocolo” es abandonar el modelo de recursos y por tanto, abandonar REST y la Web.

Lo más importante de todo es tener en la mente que REST trata de exponer recursos por medio de URIs, no servicios a través de interfaces de mensajes.

7.4 Conclusiones

En este capítulo se han expuesto algunos de los Servicios Web que están actualmente funcionando de acuerdo al modelo de arquitectura REST. Además se han proporcionado un ejemplo para comprender mejor el diseño de un Servicio Web y un artículo que enumera los principales errores de implementación.. En el siguiente capítulo se hará un seguimiento de la relevancia que ha tenido REST en la Web desde que salió a la luz. Además se intentará dar una previsión del futuro que le espera a REST.

8 EVOLUCIÓN Y FUTURO DE REST

En este capítulo se hace un seguimiento de la relevancia que ha tenido REST en la Web desde que salió a la luz. Además se intenta dar una previsión del futuro que le espera a REST.

Los adeptos a REST siempre han presumido de que la mayor parte de la red (las páginas Web), hace uso de un diseño REST. Sin embargo, cuando hablamos de implementar Servicios Web con una mínima complejidad, a día de hoy, SOAP posee el monopolio casi absoluto. Las implementaciones que hay realizadas en REST van aumentando a paso lento, por lo que el futuro que le espera es aún algo incierto.

8.1 Progresión de REST

En este apartado se va a comentar cómo ha variado la importancia que se le ha dado a REST en la Web.

Como se ha afirmado, REST nació en el ámbito académico de la mano de Roy Fielding. Sin embargo, se ha fraguado en la red de manera “extraoficial”. Toda la información que existe se basa en blogs y artículos que distintos autores han escrito.

REST comenzó de manera “explosiva” en la Web. Cuando Roy Fielding sacó a la luz su disertación en 2002, toda la red se hizo eco de ello. Surgieron muchos artículos que cuestionaban la eficiencia de SOAP. En algunos sectores se creyó que REST podía ser

la solución al monopolio que tenía SOAP. Con SOAP, algunas empresas como Microsoft habían creado una dependencia casi absoluta en los desarrolladores de Servicios Web.

Al terminar el año 2002 hubo un silencio casi sepulcral en la red. Es difícil encontrar información sobre REST fechada en 2003 o 2004. Puede que la guerra de Irak tuviese algo que ver con todo esto, por una posible desviación de fondos del sector académico al militar (la mayor parte de los autores que han escrito sobre REST son estadounidenses).

A partir del año 2005 vuelve a reanudarse el debate en torno a REST, aunque de una manera más débil que en 2002 y sin aportar grandes cambios a todo lo que se había discutido en los años anteriores.

A continuación podemos ver la Figura [28], que es una gráfica que expresa en tantos por cien la cantidad de información que se generó sobre REST en un determinado año, en relación a toda la documentación existente.

Figura 27: % Importancia de REST en la Web

8.2 Futuro de REST según Paul Prescod

En este apartado vamos a incluir una parte del artículo que escribió Paul Prescod [25] en 2002 (que se encuentra en el apartado DEBATE REST-SOAP), pero que debido al estancamiento que sufre REST, podemos decir que todavía es actual.

8.2.1.1 MIRANDO HACIA EL FUTURO

Hay tres posibles futuros. En uno, las críticas de REST sobre la filosofía de SOAP resultan ser incorrectas. El modelo de SOAP volvería a ser suficientemente bueno y el uso de REST se limitaría a ser el hipertexto de la Web. En un segundo escenario, la metodología de SOAP revelaría gradualmente sus defectos hasta que fuesen intratables. REST o algo parecido se convertiría en la arquitectura dominante y SOAP estaría relegado a tener un papel mucho menos importante. En el tercer escenario, encontraríamos una manera de que ambas arquitecturas trabajasen juntas. Cada una podría tratar diferentes problemas e incluso podrían interoperar.

8.2.1.2 ¿PUEDE GANAR UN SOLO PROTOCOLO?

Los negocios electrónicos van a necesitar algo más que software orientado a RPC o a mensajes. Todos los negocios tendrán que estandarizar sus modelos de direccionamiento y compartir una interfaz común con el resto de negocios. SOAP no hace esto por si mismo, en este aspecto, hace más daño de la ayuda que ofrece.

Para que los negocios puedan interoperar sin necesidad de programar manualmente los enlaces con otros negocios, necesitarán estandarizar los protocolos antes que inventar nuevos. Tendrán que estandarizar un modelo de direccionamiento antes que inventar uno nuevo. REST propone un alto grado de estandarización. Los servicios Web estarán estancados hasta que se estandaricen en una arquitectura unificada, y REST es esa arquitectura. Si esto es cierto, entonces no importa si gana REST o SOAP, porque SOAP viviría dentro de la arquitectura REST para servicios Web.

8.2.1.3 ¿PUEDEN COEXISTIR REST Y SOAP?

Recientemente SOAP ha tomado una dirección que le acerca a REST, pero también conserva su núcleo basado en RPC. La cuestión por tanto no es si SOAP y REST pueden coexistir. Pueden. Pero si la visión del mundo basado en REST es correcta, entonces todo el proyecto SOAP/WSDL sería un error. ¿Por qué necesitamos un marco de trabajo de protocolos para tunelar nuevos protocolos de aplicación sobre cualquier transporte, cuando tenemos muchos protocolos de aplicación?

Una respuesta es que SOAP está ganando en cuanto a seguridad, enrutamiento y otros aspectos que no pueden ser direccionados con HTTP, o por lo menos no tan robustamente. Un escenario horrible para la futura Web tendría un conjunto de características disponibles para SOAP (seguridad, enrutamiento…), y otro conjunto distinto para HTTP (direccionamiento, métodos conocidos…), y ninguna manera de conseguir lo mejor de ambos.

Una posible solución sería reinventar un protocolo REST (orientado a URI y genérico) en lo alto de SOAP. Lo llamaremos “SHTTP”. Sería una solución potente pero existen muchas dificultades técnicas. Dada una URI en particular, debe existir un y solo un modo de mapear la URI en una representación. Por tanto, se requeriría un nuevo esquema URI. Este nuevo esquema URI sería incompatible con la gran variedad de clientes HTTP que hay desarrollados y podría tardar años en propagarse.

Además, HTTP se usa constantemente para repartir datos binarios, pero SOAP no es bueno en ese aspecto. Los motores HTTP son más eficientes que las herramientas que deben parsear XML. Hay otro problema por el que los mensajes SHTTP no podrían correr en lo alto de SOAP, SOAP suele ir encima de HTTP. Esto es ineficiente, confuso y puede desembocar en agujeros de seguridad donde el mensaje de la capa SHTTP es muy distinto al que envía la capa HTTP.

Pero lo más importante, aunque superemos estas incoherencias sintácticas, no responderíamos a ninguna de las cuestiones que surgieron en la crítica de REST a SOAP. ¿Necesitamos muchos protocolos o sólo uno?, ¿Necesitamos muchos modelos de direccionamiento, o sólo uno?, ¿Podemos conseguir la interoperabilidad con un sistema que usa múltiples protocolos y modelos de direccionamiento?, ¿Es realmente algo idealizado conseguir unificar todo en un simple protocolo y un modelo de direccionamiento?, ¿Debemos exponer servicios o eliminar los límites de los servicios y exponer recursos?, ¿Deben ser prescriptivos o descriptivos los servicios Web estándar?, ¿Se puede manejar la herencia sólo con gateways?, ¿Cambiarían las respuestas a esas preguntas si integrásemos las aplicaciones dentro de organizaciones en vez de tener límites organizacionales?

Cada parte cree conocer las respuestas. Sólo el tiempo demostrará qué visión es la correcta.

8.3 Reflexión personal sobre el futuro de REST

Puede que una de las causas por las que REST no termina de despegar los suficiente como para hacerle sombra a SOAP sea la falta de organización y la escasez de documentación útil.

Sólo existe un documento “oficial” sobre REST, que es la disertación de Fielding. Después de exponerla, permaneció en la sombra. La repercusión de todo esto es que nadie ha llevado las riendas de REST, y toda la información que existe son artículos y blogs que hay “esparcidos” por la red. En estos artículos, cada autor da su interpretación de REST, por lo que a veces encontramos información contradictoria o de dudosa credibilidad.

Si alguien quiere desarrollar su primer Servicio Web al estilo REST, primero leerá la disertación de Roy Fielding para posteriormente investigar sus dudas por la red. Pero lo más probable es que esta persona no saque una idea en claro y decida desarrollar su Servicio Web con otra tecnología.

Lo que a un usuario cualquiera le gustaría encontrar es algún tipo de normativa o documentación “oficial” sobre el tema y muchos ejemplos prácticos. Por desgracia, de momento esto todavía no se ha logrado para REST.

No existe una organización o entidad que agrupe y ordene el conocimiento y los avances que van produciéndose en el mundo de REST para acercárselo al público, y

puede que de no ser así, REST acabe como una utopía, una buena idea que jamás llegó a cuajar.

9 TEMPORIZACIÓN Y PRESUPUESTO

En este capítulo se detalla el tiempo que se ha tardado en realizar el proyecto y se desglosan los gastos que se derivan de él.

9.1 Temporización

En este apartado se va a detallar el tiempo invertido en realizar el proyecto y las distintas fases que ha tenido.

El proyecto se puede dividir en cuatro fases o procesos:

Una primera fase que consiste en explorar la red recogiendo toda la información posible sobre los Servicios Web y REST en particular.

Una segunda fase de asimilación y selección de la información más importante, evitando repetir contenidos.

Una tercera fase en la que había que traducir al castellano toda la información.

Una cuarta fase en la que se ha confeccionado la memoria.

A continuación puede verse la Figura [29], que es una gráfica donde se observa la duración de cada fase en el proceso de elaboración del proyecto.

Figura 28: Temporización del proyecto

La duración total del proyecto ha sido de ocho meses. La primera fase se ha extendido desde Noviembre hasta mediados de Abril. La segunda desde Noviembre hasta finales de Abril. La tercera desde mediados de Noviembre hasta la mitad de Abril. La cuarta desde Febrero hasta mediados de Junio.

9.2 Presupuesto

En este apartado se realizará un presupuesto detallado de los costes que se derivan de la realización del proyecto. Estos gastos se dividen en varias categorías: costes de personal, costes de Hardware, costes de Software y otros gastos.

9.2.1 Costes de personal

Si suponemos que se ha desempeñado una jornada de trabajo básica de 40 horas semanales y que se puede establecer un sueldo base de unos 1500 € mensuales para un ingeniero junior, el coste de personal de este proyecto asciende a:

Personas Tiempo Sueldo Subtotal1 7,5 meses 1500 € / mes 11250 €

Subtotal 11250 €

Tabla 9 Costes de personal

9.2.2 Costes de Software

El software necesario para llevar a cabo el proyecto ha sido:

Sistema Operativo Windows XP Home Edition Paquete Microsoft Office XP

Por tanto el coste de Software derivado del proyecto asciende a:

Software Unidades Precio/Unidad SubtotalS.O. Windows 1 180,00 € 180,00 €Office XP 1 83,90 € 83,90 €

Subtotal 263,9 €

Tabla 10 Costes de Software

9.2.3 Costes de Hardware

El coste de Hardware ha sido el derivado del uso de un ordenador portátil, por lo que el importe asciende a:

Equipo Número Coste SubtotalOrdenador Portátil 1 1200 € 1200 €

Subtotal 1200 €

Tabla 11 Costes de Hardware

9.2.4 Otros costes

Esta clasificación engloba al resto de gastos que no han sido incluidos en los otros apartados. El importe de estos costes se desglosa de la siguiente manera:

Descripción Cantidad Coste SubtotalMaterial de Oficina 1 30 € 30 €Electricidad 7,5 meses 8 € / mes 60 €Transportes 1 20 € 20 €

Subtotal 110 €

Tabla 12 Otros Costes

9.2.5 Resumen presupuestario

Todos los costes anteriormente desglosados se resumen en la Tabla [12]

Descripción CosteCostes de Personal 11250 €

Coste software 263,9 € Coste hardware 1200 € Otros costes 110 €

Total 12823,9 €

Tabla 13 Total Costes

Como puede verse, la mayor parte del presupuesto recae en los Costes de personal. Esto era algo de esperar en un proyecto de documentación.

10 BIBLIOGRAFÍA:

En este capítulo se va a exponer la bibliografía utilizada para confeccionar el proyecto.

10.1 Bibliografía procedente de la Web

[1] W3C: http://www.w3c.es/Divulgacion/Guiasbreves/ServiciosWeb

[2] Wikipedia: http://es.wikipedia.org/wiki/Servicio_Web

[3] Wikipedia: http://es.wikipedia.org/wiki/URI

[4] Wikipedia: http://es.wikipedia.org/wiki/URL

[5] Benjamín González [2005]

http://www.desarrolloweb.com/articulos/1581.php?manual=54

[6] Roger L. Costello [2002]: http://www.xfront.com/REST-Web-Services.html

[7] Paul Prescod [2002]: http://www.prescod.net/rest/mistakes/

[8] Ajax Pattern: http://ajaxpatterns.org/RESTful_Service

[9] Roger Costello [2002]: http://www.xfront.com/REST-Web-Services.html

[10] Paul Prescod [2002]: http://www.prescod.net/rest/mistakes/

[11] David Megginson [2005]:

http://www.megginson.com/blogs/quoderat/archives/2005/02/14/rest-design-

questions/

[12] ebPML.org [2006]: http://www.ebpml.org/amazon.htm?T1=BPEL&B3

[13] Paul Prescod [2002]: http://www.prescod.net/rest/rest_vs_soap_overview/

[14] Paul Prescod [2002]: http://www.prescod.net/rest/rest_vs_soap_overview/

[15] Paul Prescod [2002]: http://www.prescod.net/rest/security.html

[16] Robert McMillan [2002]: http://www.oetrends.com/cgi-bin/page_display.cgi?82

[17] Robert McMillan [2003]: http://www.networkworld.com/ee/2003/eerest.html

[18] Roy Hoobler [2002]:

http://searchwebservices.techtarget.com/qna/0,289202,sid26_gci823342,00.html

[19] Amit Asaravala [2002]: http://www.devx.com/DevX/Article/8155

[20] Sam Ruby [2002]: http://www.intertwingly.net/stories/2002/07/20/restSoap.html

[21] Tim Bray [2003]:

http://www.tbray.org/ongoing/When/200x/2003/05/12/SoapAgain

[22] Benjamin Carlyle [2005]: http://soundadvice.id.au/blog/2005/07/05/

[23] Disenchanted dictionary [2002]: http://www.disenchanted.com/dis/lookup?

node=1837&context=1633

[24] eBay REST API [2004]: http://developer.ebay.com/developercenter/rest

[25] Paul Prescod [2002]: http://www.prescod.net/rest/rest_vs_soap_overview/

[26] Jérôme Louvel [2006]: http://www.restlet.org/introduction

[27] Wikipedia: http://en.wikipedia.org/wiki/UUID

10.2 Especificaciones consultadas

[RFC 1738], URL: http://www.faqs.org/rfcs/rfc1738.html

[RFC 2396], URI: http://www.faqs.org/rfcs/rfc2396.html

[RFC 1630], URI (1994): http://www.faqs.org/rfcs/rfc1630.html

[RFC 4122], UUID: http://tools.ietf.org/html/4122

[RFC 1945], HTTP: http://www.faqs.org/rfcs/rfc1945.html

[RFC 1036], Formato Date HTTP: http://www.faqs.org/rfcs/rfc1036.html

[RFC 1123], Formato Date HTTP: http://www.ietf.org/rfc/rfc1123.txt

[W3C-WSDL 1.1]: http://www.w3.org/TR/wsdl

[W3C-XML]: http://www.w3.org/TR/2000/REC-xml-20001006

[W3C-SOAP]: http://www.w3.org/TR/2002/WD-soap12-part0-20020626/

[disertación] Roy Thomas Fielding:

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

10.3 Bibliografía procedente de libros

T. Berners-Lee, R. Cailliau, and J.-F. Groff. World Wide Web. Flyer distributed atthe 3rd Joint European Networking Conference, Innsbruck, Austria, May 1992.

T. Berners-Lee. Universal Resource Identifiers in WWW. Internet RFC 1630,June 1994.

T. Berners-Lee, R. Cailliau, A. Luotonen, H. Frystyk Nielsen, and A. Secret. TheWorld-Wide Web. Communications of the ACM, 37(8), Aug. 1994, pp. 76–82.

P. Bernstein. Middleware: A model for distributed systems services.Communications of the ACM, Feb. 1996, pp. 86–98.

A. D. Birrell and B. J. Nelson. Implementing remote procedure call. ACMTransactions on Computer Systems, 2, Jan. 1984, pp. 39–59.

M. Boasson. The artistry of software architecture. IEEE Software, 12(6),Nov. 1995, pp. 13–16.154

G. Booch. Object-oriented development. IEEE Transactions on Software

Engineering, 12(2), Feb. 1986, pp. 211–221.

F. Buschmann and R. Meunier. A system of patterns. Coplien and Schmidt (eds.),Pattern Languages of Program Design, Addison-Wesley, 1995, pp. 325–343.

M. R. Cagan. The HP SoftBench Environment: An architecture for a newqeneration of software tools. Hewlett-Packard Journal, 41(3), June 1990,pp. 36–47.

J. R. Cameron. An overview of JSD. IEEE Transactions on Software Engineering,12(2), Feb. 1986, pp. 222–240.

R. S. Chin and S. T. Chanson. Distributed object-based programming systems.ACM Computing Surveys, 23(1), Mar. 1991, pp. 91–124.

D. D. Clark and D. L. Tennenhouse. Architectural considerations for a newgeneration of protocols. In Proceedings of ACM SIGCOMM‘90 Symposium,Philadelphia, PA, Sep. 1990, pp. 200–208.

J. O. Coplien and D. C. Schmidt, ed. Pattern Languages of Program Design.Addison-Wesley, Reading, Mass., 1995.

D. Flanagan. JavaTM in a Nutshell, 3rd edition. O’Reilly & Associates, Sebastopol,CA, 1999.

J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen,E. Sink, and L. Stewart. HTTP Authentication: Basic and Digest AccessAuthentication. Internet RFC 2617, June 1999.

N. Freed and N. Borenstein. Multipurpose Internet Mail Extensions (MIME) PartOne: Format of Internet Message Bodies. Internet RFC 2045, Nov. 1996.

M. Fridrich and W. Older. Helix: The architecture of the XMS distributed filesystem. IEEE Software, 2, May 1985, pp. 21–29.

A. Fuggetta, G. P. Picco, and G. Vigna. Understanding code mobility. IEEETransactions on Software Engineering, 24(5), May 1998, pp. 342–361.