REST (Representational State Transfer): 2, Motivación y principios

Leyendo mi anterior entrada sobre REST, nos podemos hacer una idea de lo que significa REST, pero no encontramos nada realmente “nuevo”.

La motivación de REST es el capturar las características de Internet que la han hecho tan exitosa. Sin embargo, REST no se convierte en un estandar, ni mucho menos, REST es un estilo a la hora de crear la arquitectura de un sitio web. Sin embargo, REST si que se apoya en estándares:

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.

Referencias: Estos dos post de introducción a REST están extraídos y traducidos, básicamente, del artículo “A brief introduction to REST” de InfoQ y el artículo “Building Web Services the REST way” de Roger L. Costello en xFront.