Que significa RESTafarian

Un restafarian es un sostenedor, defensor de la arquitectura REST propuesta por Roy Fielding, la profecia RESTafarian sostiene que todas las aplicaciones (menos las RESTfull) tendrán dificultades para gestionar el cambio y evitar la ruptura de clientes fuertemente acoplados. Esto tendrá un impacto negativo en la velocidad y el costo de la innovación esto los hara menos competitivo a través del tiempo.

Que es REST ?  (Representational State Transfer)

Es un estilo de arquitectura para sistemas distribuidos,el término se originó en el año 2000 en la tesis doctoral Architectural Styles and the Design of Network-based Software Architectures escrita por Roy Fielding, uno de los principales autores de la especificación del protocolo HTTP.


Los principios de REST

Identificación de recursos
Los recursos se separan para ser enviados al cliente

Manipulación de recursos
El cliente puede manipular los recursos con la representación. El diseño debe estar orientado  a los recursos.

        http://api.zonajobs.com/users/create?userId=235

        http://api.zonajobs.com/users/retrieve?userId=235

        http://api.zonajobs.com/users/update?userId=235

        http://api.zonajobs.com/users/delete?userId=235

        http://api.zonajobs.com/users/retrieveAll

        http://example.com/customers/1234

        http://example.com/orders/2007/10/776654

        http://example.com/product/4554

        http://example.com/processes/sal-increase-234

Mensaje auto descriptivo
Cada mensaje incluye suficiente información descriptiva sobre su procesamiento

HATEOAS 

Hypertext As The Engine Of Application State, es el motor de estado de la aplicación, este principio sostiene que un cliente debe interactuar con una aplicación enteramente a través de referencias hypermedia provistas dinámicamente por el servidor,un cliente dentro de un contexto REST no debe tener nigún conocimiento previo de la API más alla de un punto de entrada y un entendimiento general del funcionamiento de un sistema hypermedia. 

Figura 1

Figura 2

Las restrincciones (constraints) REST recomendable para construir una API RESTfull 

1. Interfaz uniforme

La restricción de interfaz uniforme define la interfaz entre clientes y servidores. Simplifica y desacopla la arquitectura, que permite a cada parte a evolucionar de forma independiente 

Verbos HTTP (CRUD) 
URI (nombre del recurso) 
Respuesta HTTP (estado, cuerpo)


2. Sin estado

• El Server no almacena ningún estado cliente
• Cada petición (request) contiene suficiente contexto para procesar el mensaje (auto mensajes descriptivos)
• Cualquier estado de sesión se lleva a cabo en el cliente proporcionándonos : - - Visibilidad, Confiabilidad y Escalabilidad.

Visibilidad : se mejora debido a que no se tiene que mirar una sola solicitud de fin de determinar su naturaleza.
Confiabilidad : la mejora por que facilita la tareas de recuperación de fallos parciales.
Escalabilidad : se mejora debido a que no tenemos que almacenar el estado entre peticiones , esto permite que el server reparta sus recursos rápidamente.

3. Cache

Como en la World Wide Web, los clientes/CDN puede almacenar en caché las respuestas. 

Esto nos da la ventaja de tener el potencial para eliminar parcial o completamente algunas interacciones, mejorando la eficiencia 

Cada solicitud debe declarar sus propias regla de caché: 
     Implícitamente 
     Explícitamente 

     Negocio

4. Cliente - Servidor

• La separacion de las responsbilidades es el principio detras de la restriccion cliente-servidor.
• Al separar las preocupaciones de la interfaz de usuario de las preocupaciones de almacenamiento de datos, mejoramos la portabilidad de la interfaz de usuario a través de múltiples plataformas y mejoramos la escalabilidad mediante la simplificación de los componentes del servidor.
• Componentes para evolucionar de forma independiente

5. Sistema de capas

Un cliente no necesita conocer con quien esta conectado.

La principal desventaja de los sistemas de capas es que añaden sobrecarga y la latencia para el tratamiento de datos.

6. Codigo en las demandas

El server son capaces de extenderse de manera temporal o personalizar la funcionalidad de un cliente por la logica de transferencia.
La replica puede ser un archivo javascript o java applet.

HTTP

REST utliza este protocolo de peticion y respuesta (request/response)

Figura 3

Request / Response :

HTTP verbos

Recurso	GET	POST	PUT	DELETE
URI	Read	Create	Update	Delete
api.mydomain.com/formularios	Traer todas los Formularios	Error	Error	Borrar todos los Formularios
api.mydomain.com/formularios/1234	Traer un Formulario pagina	Create Formulario	Si existe actualiza el Formulario	Borrar un Formulario

Tipos de respuestas

Generalmente utilizando los codigos de estado HTTP para describir el resultado :

1xx: Infomration (100: continute...)

2xx: Success (200:ok, 201: created...)

3xx: Redirection (301: moved permanently)

4xx: Client error (400: bad request, 404: not found...

5xx: Server error (500: internal error, 501: not impl...)

REST web service API's populares 

https://developer.linkedin.com/apis

http://developers.facebook.com/docs/reference/api/

https://dev.twitter.com/docs/api

http://docs.amazonwebservices.com/AmazonS3/latest/API/APIRest.html

http://developer.nytimes.com/docs/article_search_api

https://developers.google.com/translate/v2/using_rest

Figura 5