¿Que es REST?

Lo primero es aclarar que REST no es una tecnología, ni siquiera una arquitectura, sino una familia de arquitecturas. Cualquier arquitectura de servicios distribuidos que cumpla con una serie de requisitos se puede considerar como una arquitectura REST. Estos requisitos o propiedades son los siguientes:

• No se publican servicios RPC. En arquitecturas REST, los servicios no publican un conjunto arbitrario de métodos u operaciones. Por ejemplo, en REST no podemos publicar una interfaz “IGestionEmpleados” con métodos “addEmpleado”, “removeEmpleado” o “buscarEmpleadosEnEdadDeJubilacion”. 
• En REST lo que se publica son recursos. Un recurso se puede considerar como una entidad que representa un concepto de negocio que puede ser accedido públicamente. Un ejemplo de recurso sería simplemente “EmpleadosDeLaEmpresa” y otro podría ser “Empleado número 33″ 
• Si no podemos definir operaciones arbitrarias sobre el recurso, ¿cómo podemos operar con él? En REST todos los recursos comparten una interfaz única y constante. Todos los recursos tienen las mismas operaciones. Las operaciones nos permiten manipular el estado público del recurso. En un sistema REST típico se definen cuatro operaciones. 
• CREATE. En esta operación el cliente manda al servidor una petición para crear un nuevo recurso. Opcionalmente el cliente puede mandar una representación del estado inicial de este recurso. El servidor responde con el identificador global del nuevo recurso. 
• DELETE. En esta operación el cliente elimina un recurso del servidor. El cliente necesita saber el identificador del recurso. 
• READ. Con esta operación el cliente puede leer una representación del estado de un recurso, identificado con su identificador global. El cliente puede especificar que tipos de representaciones entiende. Aquí lo que ocurre realmente es que se copia el estado del recurso en el servidor y se pega en el cliente. Ambas copias del estado no se mantiene sincronizadas. El servidor puede cambiar el estado real del recurso y el cliente, de forma independiente, puede modificar su copia local del estado del recurso. 
• UPDATE. Como el servidor y el cliente tienen una copia diferente del estado, el cliente puede usar esta operación para sobrescribir o grabar su copia del estado en el servidor. De esta manera se puede actualizar el estado del recurso con las modificaciones hechas en el cliente. 
• La implementación del servicio es libre de prohibir alguno de estos métodos para un recurso en concreto. También debe definir el modelo de datos que se va a publicar y que representaciones soporta. Lo que no puede hacer es inventarse operaciones de forma arbitraria. Las operaciones son siempre las mismas. 
• Los distintos recursos se pueden interrelacionar y referenciar entre si mediante sus identificadores globales.

Una confusión típica es pensar que REST no es más que un CRUD llevado a la web, ¿no será mi BBDD relacional un sistema REST? No exactamente. Es parecido, pero existen algunas diferencias sutiles e importantes entre un CRUD simple o una BBDD con una arquitectura REST:

• Al contrario que en un CRUD típico, como una BBDD, el servidor puede soportar muchas representaciones de un mismo recurso: xml, pdf, png, gif, excel, html, json, texto, etc.. Hay pocas BBDD que hagan esto. 
• No penséis que las operaciones REST se limitan a hacer CRUD tradicional, no se trata solo de persistir nuestros cambios. Cuando hacemos un UPDATE, nuestra implementación del recurso además de grabar el estado en soporte persistente, debe hacer otras cosas, como validaciones de negocio o actualizaciones en otros recursos para mantener la consistencia global del sistema. Esto sí que se parece a una BBDD con triggers e integridad referencial, pero no es CRUD en el sentido de que no nos limitamos a grabar y ya está. Una DAO es CRUD, un recurso REST no (excepto en los casos más simples). 
• Los recursos mantiene interrelaciones entre si. La topología de estas interrelaciones es compleja, puede ser un grafo arbitrario, con ciclos, o un simple árbol. Es más, los recursos de nuestro sistema se pueden interrelacionar con recursos en sistemas de terceras partes, ya que el identificador es único y global.

Pues resulta que REST es un enfoque maduro con un claro ejemplo existente en la actualidad: la world wide web. Veamos si la web tiene propiedades REST:

• La web está compuesta de recursos, cada página web puede considerarse un recurso. 
• Cada recurso tiene un identificador único global, que es su URI (o URL para los antiguos o IRI para los más modernos). Usando una URL podemos llegar a cualquier recurso en la web. 
• Dada una URI, y mediante el protocolo HTTP, podemos operar sobre estos recursos. La operación a realizar se especifica mediante el verbo HTTP. Mediante cabeceras especiales como Accept o Content-Type se puede especificar que representaciones entienden el servidor y el cliente y que representación se usa en un mensaje concreto para transporta el estado del recurso. 
• El verbo GET hace la operación READ. 
• El verbo DELETE hace la operación DELETE. 
• El verbo PUT se usa normalmente para hacer UPDATE 
• El verbo POST se usa normalmente para hacer CREATE. 
• Las representaciones a usar se especifican mediante los llamados tipos mime. La mayoría de los tipos mime son estándares, como xml o json. El usar tipos mime estándar facilita la interoperabilidad. 
• La aplicación cliente típica de la web es el navegador. Los navegadores se dedican a hacer GETs sobre URIs para obtener representaciones de las distintas páginas web. En el caso habitual cada página sólo admite una representación, típicamente HTML o PDF o texto plano o imágenes. Pero eso no significa que una misma URI no pudiera soportar distintas representaciones.

Lo interesante de todo esto es que la web es un ejemplo perfecto de servicios distribuidos a nivel global totalmente interoperable (o casi). La web, y el protocolo HTTP es una arquitectura REST. La web son servicios REST que en general sólo soportan HTML. Casi cualquier página HTML es interoperable con casi cualquier navegador, y casi cualquier página HTML puede interoperar (referenciar) con otra página HTML construida por un tercero. Es sorprendente que con este claro ejemplo, presente en nuestro día a día, llegada la hora de pensar en como hacer servicios web, no se viera lo que tenemos delante de la cara, sino que se inventara algo como SOAP y WSDL.