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............................................................................................................10
2 INTRODUCCIÓN...................................................................................................11
2.1 Temática de los capítulos................................................................................12
3 CONCEPTOS PREVIOS........................................................................................14
3.1 URL.................................................................................................................14
3.1.1 Sintaxis....................................................................................................15
3.1.2 URI y Referencias URI...........................................................................17
3.1.3 Diferenciación entre mayúsculas/minúsculas..........................................19
3.1.4 URLs en el uso diario..............................................................................19
3.1.5 El gran marco..........................................................................................20
3.2 UUID...............................................................................................................21
3.3 HTTP...............................................................................................................21
3.3.1 Características y funcionamiento............................................................21
3.3.2 Comandos del protocolo HTTP...............................................................24
3.4 XML................................................................................................................29
3.4.1 Conceptos básicos...................................................................................30
3.4.2 DTD: Definición de Tipos de Documentos.............................................32
3.4.3 Entidades.................................................................................................36
3.4.4 Modelo de Objetos de Documentos: DOM.............................................37
3.5 Conclusiones....................................................................................................38
4 SOAP Y WSDL.......................................................................................................39
4.1 SOAP...............................................................................................................39
4.1.1 Concepto de SOAP..................................................................................39
4.1.2 Objetivos de SOAP..................................................................................40
4.1.3 Un ejemplo sencillo de mensajes SOAP.................................................41
4.1.4 Serialización............................................................................................43
4.1.5 Protocolo HTTP mediante SOAP............................................................46
4.2 WSDL..............................................................................................................48
4.3 Conclusiones....................................................................................................52
5 REPRESENTATIONAL STATE TRANSFER: REST..........................................53
5.1 Introducción.....................................................................................................53
5.2 Origen de REST, Roy Thomas Fielding..........................................................54
5.3 Objetivos..........................................................................................................55
5.4 Restricciones de REST....................................................................................55
5.4.1 Cliente-Servidor......................................................................................55
5.4.2 Sin estado (Stateless)...............................................................................56
5.4.3 Caché.......................................................................................................57
5.4.4 Interfaz uniforme.....................................................................................58
5.4.5 Sistema de capas......................................................................................58
5.4.6 Código bajo demanda..............................................................................59
5.5 Elementos arquitectónicos de REST...............................................................59
5.5.1 Datos en REST........................................................................................59
5.5.2 Conectores en REST................................................................................64
5.5.3 Componentes en REST............................................................................67
5.6 Vistas de la arquitectura REST........................................................................68
5.6.1 Vista de proceso......................................................................................68
 5.6.2 Vista de conector.....................................................................................70
5.6.3 Vista de datos..........................................................................................71
5.7 HTTP, URI y XML en REST.........................................................................73
5.7.1 Estandarizando la Web............................................................................73
5.7.2 REST aplicado a URI..............................................................................74
5.7.3 REST aplicado a HTTP...........................................................................79
5.7.4 REST y XML..........................................................................................87
5.7.5 Repercusiones de usar HTTP y URI.......................................................88
5.8 Cuestiones por resolver...................................................................................88
5.8.1 David Megginson....................................................................................89
5.8.2 [Link]...............................................................................................98
5.9 Conclusiones....................................................................................................99
6 DEBATE REST-SOAP.........................................................................................100
6.1 PAUL PRESCOD..........................................................................................101
6.1.1 Raíces del debate REST-SOAP [14].....................................................101
6.1.2 Algunos pensamientos sobre la seguridad de REST-SOAP [15]..........109
6.2 ROBERT McMILLAN.................................................................................112
6.2.1 REST, sustituto de SOAP-RPC [16].....................................................112
6.2.2 Una aproximación a los Servicios Web basada en REST [17].............113
6.3 ROY HOOBLER...........................................................................................115
6.3.1 REST puede acabar con SOAP [18]......................................................115
6.4 AMIT ASARAVALA...................................................................................117
6.4.1 Dando un descanso (REST) a SOAP [19].............................................118
6.5 SAM RUBY..................................................................................................120
6.5.1 REST + SOAP [20]...............................................................................120
6.6 TIM BRAY....................................................................................................121
6.6.1 The SOAP/XML-RPC/REST SAGA [21]............................................121
6.7 BENJAMIN CARLYLE...............................................................................124
6.7.1 REST vs Orientación a Objetos [22].....................................................124
6.8 Disenchanted dictionary................................................................................127
6.8.1 REST [23].............................................................................................127
6.9 Conclusiones..................................................................................................129
7 IMPLEMENTACIONES......................................................................................130
7.1 Implementaciones REST en la Web..............................................................130
7.1.1 Amazon..................................................................................................130
7.1.2 eBay.......................................................................................................131
7.1.3 Restlets..................................................................................................131
7.2 Ejemplo de uso de REST...............................................................................132
7.2.1 Conseguir una lista de las partes..........................................................133
7.2.2 Conseguir datos detallados de una parte...............................................133
7.2.3 Emitir una PO (orden de compra).........................................................134
7.3 Errores comunes a la hora de diseñar con REST..........................................134
7.4 Conclusiones..................................................................................................137
8 EVOLUCIÓN Y FUTURO DE REST..................................................................138
8.1 Progresión de REST......................................................................................138
8.2 Futuro de REST según Paul Prescod.............................................................139
8.3 Reflexión personal sobre el futuro de REST.................................................141
9 TEMPORIZACIÓN Y PRESUPUESTO..............................................................142
9.1 Temporización...............................................................................................142
9.2 Presupuesto....................................................................................................143
 9.2.1 Costes de personal.................................................................................143
9.2.2 Costes de Software................................................................................143
9.2.3 Costes de Hardware...............................................................................144
9.2.4 Otros costes...........................................................................................144
9.2.5 Resumen presupuestario........................................................................144
10 BIBLIOGRAFÍA:..............................................................................................146
10.1 Bibliografía procedente de la Web................................................................146
10.2 Especificaciones consultadas.........................................................................147
10.3 Bibliografía procedente de libros..................................................................148
INDICE DE FIGURAS

Figura 1: Servicios Web..................................................................................................12

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

Tabla 1 Lista de códigos de estado http...........................................................................29

Tabla 2 Mapeo entre tipos SOAP y JAVA......................................................................44
Tabla 3 Tipos de diseño de datos....................................................................................60
Tabla 4 Elementos de Datos REST.................................................................................64
Tabla 5 Conectores REST...............................................................................................67
Tabla 6 Componentes REST...........................................................................................68
Tabla 7 Significado mensajes HTTP...............................................................................81
Tabla 8 Métodos REST...................................................................................................87
Tabla 9 Costes de personal............................................................................................143
Tabla 10 Costes de Software.........................................................................................143
Tabla 11 Costes de Hardware........................................................................................144
Tabla 12 Otros Costes...................................................................................................144
Tabla 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
[Link] en vez de [Link]
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: [Link]

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

Locators.

[Link] 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].

[Link] 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.

[Link].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, [Link].:
[Link], [Link], 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 [Link] 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:,
[Link] ftp:
 Nombre del recurso, por ejemplo "//[Link]"

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:

 [Link]
 [Link]
Ejemplos de URLs relativos:
 //[Link]/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:

[Link]

Donde:
 http es el protocolo,
 [Link] 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 " [Link] 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
[Link]/wiki/Train. Para ir a una página principal normalmente se entra
sólo el nombre de anfitrión, como [Link].

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 [Link]/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
[Link] 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.

La operación ha sido realizada correctamente, y como
resultado se ha creado un nuevo objeto, cuya URL de acceso se
201 Created proporciona en el cuerpo de la respuesta. Este nuevo objeto ya
está disponible. Puede ser utilizado en sistemas de edición de
documentos.
La operación ha sido realizada correctamente, y como
resultado se ha creado un nuevo objeto, cuya URL de acceso se
202 Accepted 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.
La operación ha sido aceptada, pero no ha producido ningún
204 No Content resultado de interés. El cliente no deberá modificar el
documento que está mostrando en este momento.
El objeto al que se accede ha sido movido a otro lugar de
forma permanente. El servidor proporciona, además, la nueva
Moved
301 URL en la variable Location de la respuesta. Algunos browsers
Permanently
acceden automáticamente a la nueva URL. En caso de tener
capacidad, el cliente puede actualizar la URL incorrecta.
El objeto al que se accede ha sido movido a otro lugar de
forma temporal. El servidor proporciona, además, la nueva
Moved
302 URL en la variable Location de la respuesta. Algunos browsers
Temporarily
acceden automáticamente a la nueva URL. El cliente no debe
modificar ninguna de las referencias a la URL errónea.
Cuando se hace un GET condicional, y el documento no ha
304 Not Modified
sido modificado, se devuelve este código de estado.
La petición tiene un error de sintaxis y no es entendida por el
400 Bad Request
servidor.
La petición requiere una autorización especial, que
normalmente consiste en un nombre y clave que el servidor
401 Unauthorized
verificará. El campo WWW-Autenticate informa de los
protocolos de autentificación aceptados para este recurso.
Está prohibido el acceso a este recurso. No es posible utilizar
403 Forbidden
una clave para modificar la protección.
404 Not Found La URL solicitada no existe.
Internal El servidor ha tenido un error interno, y no puede continuar
500
Server Error con el procesamiento.
501 Not El servidor no tiene capacidad, por su diseño interno, para
 Implemented llevar a cabo el requerimiento del cliente.
El servidor, que está actuando como Proxy o pasarela, ha
502 Bad Gateway encontrado un error al acceder al recurso que había solicitado
el cliente.
Service El servidor está actualmente deshabilitado, y no es capaz de
503
Unavailable 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 “[Link]

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 [Link] >

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="[Link]
SOAP-ENV:encodingStyle="[Link]

<SOAP-ENV:Body>

<getQuote xmlns="[Link]
<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="[Link]
SOAP-ENV:encodingStyle="[Link]

<SOAP-ENV:Body>

<Quote xmlns="[Link]
<Price>4.12</Price>
</Quote>

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

[Link] 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="[Link]
SOAP- ENV:encodingStyle= "[Link]

<SOAP-ENV:Header>
<t:Transaction xmlns:t="some-URI" SOAP-ENV:mustUnderstand="1">
5
</t:Transaction>
</SOAP-ENV:Header>

<SOAP-ENV:Body>
<getQuote xmlns= "[Link]
<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="[Link]
SOAP-ENV:encodingStyle= "[Link]

<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:

 [Link] y
 [Link] [Link]

Todo mensaje SOAP debe tener un elemento Envelope asociado a la dirección de red
[Link] 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 [Link]
SOAP-ENC:long [Link]
SOAP-ENC:short [Link]
SOAP-ENC:string [Link]
SOAP-ENC:bolean [Link]
SOAP-ENC:flota [Link]
SOAP-ENC:double [Link]
SOAP-ENC:byte [Link]

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="[Link]
<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
[Link] bajo el control del usuario de nombre elharo:

POST /xml/cgi-bin/SOAPHandler HTTP/1.1

 Content-Type: text/xml; charset="utf-8"
Content-Length: 267
SOAPAction: "[Link]

<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="[Link] >

<SOAP-ENV:Body>
<getQuote xmlns="[Link]
<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 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: 260

<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="[Link]

<SOAP-ENV:Body>
<Quote xmlns="[Link]
<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

Permite que toda la Posee una gran Permite al emisor

información sobre flexibilidad permanecer simple y
la verdadera escalable, mientras
naturaleza de los que minimiza el
VENTAJAS datos siga oculta volumen de datos
dentro del transferidos
remitente.

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

Restringe la Limita la Pierde las ventajas de

funcionalidad del funcionalidad del poder ocultar la
receptor y sitúa la receptor y puede información y
mayor parte de la incrementar en requiere que el
INCONVENIENTES carga de gran manera el emisor y receptor
procesamiento en el volumen de datos entiendan los mismos
servidor, recayendo transferidos. tipos de datos.
en problemas de
escalabilidad.

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.

[Link] 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.

[Link] 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 URI
Representación Documento HTML, imagen JPEG
Metadato de representación Tipo de medio
Recurso metadato Source link
Datos 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-perl
Servidor Libwww, Apache API, NSAPI
Cache Cache del navegador
Resolver 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 IIS
Gateway Squid, CGI, Reserve Proxy
Proxy CERN Proxy, Netscape Proxy, Gauntlet
Usuario 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.
[Link] 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.

[Link] 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:
[Link] o [Link]
[Link] 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.

[Link] 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.

[Link] 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

[Link] 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.

[Link].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.
[Link].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.

[Link].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.

[Link] 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

[Link].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

[Link].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.
[Link].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.

[Link].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.

[Link].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.

[Link].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.

[Link].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.

[Link] 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.

[Link] 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)

[Link] 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
[Link] 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.

[Link].1 GET y PUT

Veamos un caso simple. Diremos que descargamos el fichero de datos XML de

[Link] 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).

[Link].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="[Link]
...
</airport>

No sabemos exactamente como trataría con esto un procesador XLink. ¿Se resolvería la
URL relativa “[Link]” como [Link] o
como [Link] 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.

[Link] 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:

[Link]

[Link]

Como todos comparten el mismo prefijo, sería razonable asumir que usar una operación
HTTP GET en ese prefijo ([Link] 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="[Link]
xml:base="[Link]
<airport-ref xlink:href="[Link]"/>
<airport-ref xlink:href="[Link]"/>
<airport-ref xlink:href="[Link]"/>
...
</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:
[Link]
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="[Link]
xml:base="[Link]
iap=yes">
<airport-ref xlink:href="[Link]"/>
<airport-ref xlink:href="[Link]"/>
<airport-ref xlink:href="[Link]"/>
...
<next-page-link xlink:href="[Link]
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:

[Link]
o
[Link]
Deberían devolver las 20 primeras referencias a aeropuertos, seguidas de un link a
[Link] 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.

[Link] 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.

[Link].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="[Link]

...</p>
<img alt="Illustration of Galileo" src="[Link]"/>
<script src="[Link]"/>

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 [Link] es más completa que el
texto alternativo “Ilustración de Galileo”

[Link].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="[Link]
xmlns:xlink="[Link]
<name>Jane Smith</name>
<date-of-birth>1970-10-11</date-of-birth>
<employer xlink:href="[Link] Widgets,
Inc.</employer>
<country-of-birth xlink:href="[Link]
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
[Link] y hay información más completa
sobre el país de nacimiento en [Link] 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?

[Link].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.

[Link] ¿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="[Link]
xmlns:xlink="[Link]
<title>Sixteen Candles</title>
<director xlink:href="[Link]"/>
<year>1984</year>
<production-companies>
<company xlink:href="[Link]"/>
<company xlink:href="[Link]"/>
</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="[Link]
xmlns:xlink="[Link]
<title>Sixteen Candles</title>
<director xlink:href="[Link]">John Hughes</director>
<year>1984</year>
<production-companies>
<company xlink:href="[Link]">Channel Pictures</company>
<company xlink:href="[Link]">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.

[Link] 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.

[Link].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="[Link]
...
</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 [Link]

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

orientada a Servicios.

El grupo [Link] [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("[Link]
[Link](account 23423532, 50 dollars)

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

bank = new SOAPProxy("[Link]

[Link](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.

[Link] 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.

[Link] 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.

[Link] 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.
[Link] 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.

[Link] 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
[Link] 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)”.

[Link] 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.

[Link] 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.

[Link] 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”.

[Link] 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

[Link] 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:
[Link]

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.

[Link] 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“
[Link] 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.

[Link] 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.

[Link] 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.

[Link] 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.

[Link] 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.

[Link] 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.

[Link] 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.

[Link] 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.

[Link] 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.

[Link] 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.

[Link] 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 [Link]

2. No debe haber constructores sin parámetros
3. 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.

[Link] ¿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
[Link] 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 [Link] (disponible en [Link]).

Permite hacer una petición asociada a la base de datos de [Link] 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 ([Link]
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

[Link]
=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:

[Link]

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="[Link]
xmlns:xlink="[Link]
<Part id="00345" xlink:href="[Link]
<Part id="00346" xlink:href="[Link]
<Part id="00347" xlink:href="[Link]
<Part id="00348" xlink:href="[Link]
</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:

[Link]

El documento que recibe el cliente como respuesta a esa petición, es el siguiente:

<?xml version="1.0"?>
<p:Part xmlns:p="[Link]
xmlns:xlink="[Link]
<Part-ID>00345</Part-ID>
<Name>Widget-A</Name>
<Description>This part is used within the frap assembly</Description>
<Specification xlink:href="[Link]
<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 [Link] 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.
[Link] 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.

[Link] ¿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.

[Link] ¿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 Subtotal

1 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 Subtotal

S.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 Subtotal

Ordenador 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 Subtotal

Material 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 Coste
Costes 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: [Link]

[2] Wikipedia: [Link]

[3] Wikipedia: [Link]

[4] Wikipedia: [Link]

[5] Benjamín González [2005]

[Link]

[6] Roger L. Costello [2002]: [Link]

[7] Paul Prescod [2002]: [Link]

[8] Ajax Pattern: [Link]

[9] Roger Costello [2002]: [Link]

[10] Paul Prescod [2002]: [Link]

[11] David Megginson [2005]:

[Link]

questions/

[12] [Link] [2006]: [Link]

[13] Paul Prescod [2002]: [Link]

[14] Paul Prescod [2002]: [Link]

[15] Paul Prescod [2002]: [Link]

[16] Robert McMillan [2002]: [Link]

[17] Robert McMillan [2003]: [Link]

[18] Roy Hoobler [2002]:

[Link]

[19] Amit Asaravala [2002]: [Link]

[20] Sam Ruby [2002]: [Link]

[21] Tim Bray [2003]:

[Link]

[22] Benjamin Carlyle [2005]: [Link]

[23] Disenchanted dictionary [2002]: [Link]

node=1837&context=1633

[24] eBay REST API [2004]: [Link]

[25] Paul Prescod [2002]: [Link]

[26] Jérôme Louvel [2006]: [Link]

[27] Wikipedia: [Link]

10.2 Especificaciones consultadas

[RFC 1738], URL: [Link]

[RFC 2396], URI: [Link]

[RFC 1630], URI (1994): [Link]

[RFC 4122], UUID: [Link]

[RFC 1945], HTTP: [Link]

[RFC 1036], Formato Date HTTP: [Link]

[RFC 1123], Formato Date HTTP: [Link]

[W3C-WSDL 1.1]: [Link]

[W3C-XML]: [Link]

[W3C-SOAP]: [Link]

[disertación] Roy Thomas Fielding:

[Link]

10.3 Bibliografía procedente de libros

T. Berners-Lee, R. Cailliau, and J.-F. Groff. World Wide Web. Flyer distributed at
the 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. The

World-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. ACM

Transactions 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 new

qeneration 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 new

generation 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 Access
Authentication. Internet RFC 2617, June 1999.

N. Freed and N. Borenstein. Multipurpose Internet Mail Extensions (MIME) Part

One: Format of Internet Message Bodies. Internet RFC 2045, Nov. 1996.

M. Fridrich and W. Older. Helix: The architecture of the XMS distributed file
system. IEEE Software, 2, May 1985, pp. 21–29.

A. Fuggetta, G. P. Picco, and G. Vigna. Understanding code mobility. IEEE

Transactions on Software Engineering, 24(5), May 1998, pp. 342–361.