Principios REST

Principios REST 

Este estilo de arquitectura en Internet, se apoya es la siguiente serie de simples principios que te permitirán explotar la arquitectura de la Web al máximo: 

• Dale un ID a cada recurso: Esto es más simple de lo que parece, porque en Internet, cada recurso que pongamos disponible tendrá un URI asociado. Los URIs forman un espacio de nombres global que te permitirán identificar los recursos con un ID global. Ahora bien, el diseño de estas URIs tampoco es trivial, ya que sin un espacio de nombres consistente estaremos entorpeciendo la comunicación entre máquinas e, incluso, el futuro desarrollo de la aplicación. 
• Enlaza las cosas juntas: Siempre que se pueda, conviene, al devolver información sobre algo, adjuntar enlaces a los recursos que puedan adjuntar más información. Además, este enfoque permite enlazar recursos proporcionados por diversas máquinas de una forma transparente y simple. 
• Utiliza métodos estándares: Todos los recursos tienen una interfaz común marcada por el protocolo HTTP. Estos métodos son GET, POST, PUT, DELETE, HEAD y OPTIONS y nos permiten una forma estándar de acceder y manejar los diferentes recursos que necesitemos.
• Recursos con múltiples representaciones: ¿Cómo puede un cliente manejar los datos que le devuelve una petición GET o POST? Para esto, HTTP proporciona separación entre el manejo de los datos y la invocación a las operaciones. Si un cliente solo es capaz de manejar un determinado formato de datos, deberá especificarlo en la petición (añadiendo este tipo de formato en el accept, p.e: Accept: text/x-vcard) . De esta manera, la aplicación podrá responderle en un formato que sea capaz de manejar.  
• Comunícate sin estados: Este último principio se refiere a que se debe tratar de evitar que la comunicación con el servidor cambie el estado del mismo. REST prefiere que los cambios de estado se manejen como estados de recursos o bien se manejen en el cliente. De esta manera, como el servidor no tiene que gestionar y almacenar el estado con respecto a cada cliente, la escalabilidad se simplifica. Por otra parte, abstrae al cliente de lo que pase en el servidor o del servidor concreto con el que esté trabajando, pudiendo cambiarse sin que el cliente tenga que notar nada. 

Ejemplo de diseño basado en REST 

La Web evidentemente es un ejemplo clave de diseño basado en REST, ya que muchos principios son la base de REST. Aquí un ejemplo aplicado a Servicios Web.  

La Web consiste del protocolo HTTP, de tipos de contenido, incluyendo HTML y otras tecnologías tales como el Domain Name System (DNS).

Por otra parte, HTML puede incluir javascript y applets, los cuales dan soporte al code-on-demand, y además tiene implícitamente soporte a los vínculos. HTTP posee un interfaz uniforme para acceso a los recursos, el cual consiste de URIs, métodos, códigos de estado, cabeceras y un contenido guiado por tipos MIME.

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

Create	PUT	Insert	Pegar	>
Read	GET	Select	Copiar	<
Update	POST	Update	Pegar después	>>
Delete	DELETE	Delete	Cortar	Del/rm

El protocolo HTTP separa las nociones de un servidor y un navegador. Esto permite a la implementación cada uno variar uno del otro, basándose en el concepto cliente/servidor. Cuando utilizamos REST, HTTP no tiene estado. Cada mensaje contiene toda la información necesaria para comprender la petición cuando se combina el estado en el recurso. Como resultado, ni el cliente ni el servidor necesita mantener ningún estado en la comunicación. Cualquier estado mantenido por el servidor debe ser modelado como un recurso.  

La restricción de no mantener el estado puede ser violada mediante cookies que mantienen las sesiones. Fielding advierte del riesgo a la privacidad y seguridad que frecuentemente surge del uso de cookies, así como la confusión y errores que pueden resultar de las interacciones entre cookies y el uso del boton “Go back” del navegador.

HTTP proporciona mecanismos para el control del caching y permite que ocurra una conversación entre el navegador y la caché del mismo modo que se hace entre navegador y el servidor Web.