Servicios Web RESTful

REST es el acrónimo de REpresentational State Transfer, o Transferencia de Estado REpresentacional. Describe un estilo arquitectural para diseñar aplicaciones en red, y se presentó por primera vez en el año 2000. La idea es utilizar simplemente HTTP para realizar llamadas entre máquinas, en lugar de otros mecanismos o protocolos más complejos.

Pero, ¿en qué consiste? ¿Por qué se llama así?

El concepto más importante en REST es la existencia de recursos (elementos de información de los que se compone la Web), que pueden ser accedidos utilizando un identificador (URI). Para manipular estos recursos, los clientes y servidores de la red se comunican a través de una interfaz estándar (HTTP en este caso) e intercambian representaciones de estos.

Cuando se realizan peticiones a través de las URLs, se devuelve una representación de esos recursos, la cual deja la aplicación en un estado. Otras acciones (pedir otra URL, navegar a través de un enlace), hacen que se devuelva otro recurso, y esta nueva representación cambia de estado nuevamente la aplicación. De esta forma, con cada representación de los recursos, la aplicación cambia (transfiere) de estado.

Por lo tanto, REST define un conjunto de principios arquitectónicos para diseñar servicios web en los que los protagonistas son los recursos, incluyendo cómo se accede a su estado y cómo se transfieren a los clientes.

¿Estándar?

Ojo, REST no es un estándar con una especificación definida por el W3C. Tampoco se encarga de los detalles de implementación del servidor (es indiferente que el servicio web esté construido con PHP, servlets de Java, CGI… un servicio REST es independiente del lenguaje y de la plataforma). Es sólo un estilo que se puede seguir para diseñar un servicio web. Sin embargo, sí se basa en estándares:

• HTTP
• URL
• XML/HTML/GIF/JPEG/etc (representaciones de los recursos)
• text/xml, text/html, image/gif, image/jpeg, etc (Tipos MIME)

REST por sí solo tampoco ofrece características de seguridad, encriptación, gestión de sesiones… Por supuesto, y como en cualquier servicio web, estas funciones se pueden añadir por encima de HTTP: mediante usuarios y contraseñas, SSL, cookies…

REST ha ido teniendo una amplia acogida en toda la web y en la comunidad de desarrolladores, ya que es un modelo más fácil de usar, orientado a los recursos.

Los sistemas que siguen este esquema se denominan RESTful.

¿Y cuáles son esos principios?

Como decíamos, REST describe los fundamentos que hacen posible que la Web funcione bien y sea altamente escalable. Estos diseños fundamentales son:

• No se mantiene el estado: cada petición HTTP contiene toda la información necesaria para ser comprendida. Como resultado, ni el cliente ni el servidor necesitan recordar ningún estado de las comunicaciones entre mensajes. De esta forma, se mejora el rendimiento de los servicios y se hace más simple su diseño e implementación. En la práctica, sabemos que HTTP no mantiene estado, por ello muchas aplicaciones utilizan cookies y otros mecanismos para mantener la sesión (algunas de estas prácticas no son permitidas por REST).

• Un conjunto de operaciones bien definidas que se aplican a los recursos de forma inequívoca. En el caso de HTTP existen unas operaciones, que deben usarse de forma consecuente con la definición del protocolo:

• GET: para obtener un recurso. Debe ser idempotente.
• POST: para crear un recurso.
• PUT: para modificar un recurso o cambiar su estado.
• DELETE: para eliminar un recurso.

• Una sintaxis universal para identificar los recursos. En un sistema REST, cada recurso es direccionable únicamente a través de su URI. Estas URIs se definen de forma análoga a una estructura basada en directorios, de forma que la jerarquía es fácilmente comprensible y necesita escasa documentación.

• El formato de datos que el servicio utiliza en las peticiones y respuestas: la representación del estado de un recurso en un sistema REST es típicamente HTML o XML (a veces JSON), donde la estructura devuelta podría corresponderse con un registro de la base de datos, y el contenido de las etiquetas mostrase los valores de las filas. Esto permite que el servicio sea utilizado en diferentes plataformas, lenguajes y dispositivos.

URLs lógicas y URLs físicas

Un recurso es una entidad, un concepto. Una representación de este recurso es una manifestación concreta de éste. Cuando accedemos, por ejemplo, a la URL

http://www.misitio.com/persona/5897

se trata de una URL lógica, no física. Obviamente, no existe una página HTML estática para cada una de las personas en ese site, ni una carpeta anidada por cada nivel en la URL. De ser así, el diseño no sería muy escalable precisamente.

Simplemente, la URL contiene toda la información necesaria para acceder al recurso; el primer paso natural es el de ‘parsear’ la petición, mientras que los detalles de implementación del servidor quedan ocultos: puede tratarse, por ejemplo, de una consulta de base de datos en una tabla ‘personas’ cuyo id sea el 5897, etc.

La cuestión es que las URLs no revelan ningún tipo de información sobre los ficheros existentes, ni tampoco sobre la implementación. Ésta se debe poder cambiar sin que ello afecte a la estructura de las URLs en la página.

En próximos episodios veremos cómo podemos construir desde cero, y de una manera muy sencilla nuestro servidor web con una API REST utilizando… bueno, no os lo cuento. ¿Dejamos la incógnita unos días?