Una parte importante del desarrollo de aplicaciones web, es entender que se trata de una constante comunicación entre dos equipos, el cliente y el servidor.

Como parte del desarrollo de tu aplicación web, vas a tener que establecer reglas de comunicación entre ambos, cómo recibirás los datos, qué páginas se pueden visitar, cómo se mostrarán los recursos solicitados, etc.

Existen guías existentes, a las que llamamos arquitecturas, como el MVC, pero en este caso para definir cómo se comunican el servidor y el cliente, una de las más populares es el REpresentational State Transfer o REST por sus siglas iniciales.

Roy Fielding introdujo este concepto en el año 2000 y cambió por completo el diseño de servicios web en general. En esta arquitectura se establecen una serie de principios que definen cómo se dará la comunicación entre dos equipos.

Hoy en día, los servicios web de Google, Twitter, Github, y las aplicaciones web en general respetan estos principios para poder separar las responsabilidades del cliente, con las del servidor. Rails es un framework que basa mucha de su funcionalidad y muchas de sus convenciones en esta arquitectura, por lo que es importante aprender de ella.

Como mencionaba, existen 6 limitantes que un sistema REST debe respetar.

• Usar arquitectura cliente/servidor
• Que no puede guardar estado, es stateless
• Que puede guardar en caché información, a lo que normalmente nos referimos como cacheability
• Que el sistema puede estar basado en capas.
• Que poseen una interfaz uniforme
• Y por último, que pueda extender la funcionalidad del cliente mediante el envío de código on demand. Esta última es la única limitante opcional.

Vamos a abarcar cada una de estas características de manera independiente para que quede en tu biblioteca de conocimiento cómo se define si un sistema usa REST o no.

Primero la arquitectura cliente/servidor, la idea detrás de esta guía es la separación de responsabilidades entre el cliente y el servidor. Así el cliente no se preocupa por el almacenamiento de los datos, y el servidor no se preocupa por la interfaz y el estado de la misma.

El beneficio de este principio es la portabilidad de los elementos, la interfaz puede ser multiplataforma y evolucionar independientemente del servidor, porque ambos están desconectados y son independientes.

El segundo principio, el del no estado o statelesness que habla de cómo en la comunicación entre el cliente y el servidor no existe contexto, es decir, cada petición entre los dos componentes debe ser independiente y nunca dependerá de peticiones anteriores.

Este principio beneficia el rendimiento del servidor, ya que este no debe almacenar información innecesaria, toda la que necesita vendrá en cada petición y será desechada al completar la petición misma, por otro lado, las aplicaciones web con más demanda suelen estar conformadas de más de una computadora servidor, el principio del no estado hace más sencillo esto ya que no hay necesidad de preocuparnos por qué computadora procesa cada petición, ya que las peticiones mismas son independientes

La cacheabilidad habla de la posibilidad de que algunas respuestas puedan ser almacenadas en caché, tal como hemos platicado antes. Para temas del servidor, lo importante es que este se encargue de definir cuáles respuestas pueden ser cacheadas y cuáles no, por cuánto tiempo se pueden almacenar en caché, etc.

El principio del sistema en capas nos dice que el servidor debe estar compuesto de distintas capas, cada una con una responsabilidad única y bien definida. Ejemplos de las capas son las definidas en la arquitectura MVC que usa Rails, la de presentación o vista, la de datos o el modelo, y la del controlador que se encarga de comunicar la vista con los datos.

Las capas en REST deben ser independiente, por lo que podríamos reemplaza una sin afectar a otras, además, una capa debe comunicarse sólo con las capas adyacentes, esto quiere decir que si nuestro sistema tiene una capa de presentación, una manejadora de peticiones y una de datos, en ese orden, la capa de presentación no puede directamente comunicarse con la de datos, porque no son adyacentes, en cambio, debe hacerlo a través de su capa adyacente, la de comunicación, que efectivamente sí puede comunicarse con la de datos por estar juntas.

La interfaz uniforme es una de las piedras angulares de esta arquitectura, es junto con el principio del no estado, las dos reglas más importantes de un sistema REST, tan es así que dedicaremos un vídeo exclusivo a hablar de este tema.

En pocas palabras, este principio dicta el estándar para la interfaz de comunicación entre el cliente y el servidor, es decir el cómo se comunicarán estas dos entidades.

Estandarizar la interfaz permite que cada capa del sistema evolucione independientemente, ya que la comunicación es un estándar, no tienes que preocuparte por cómo se está desarrollando el servidor, si estás desarrollando el cliente.

Por último tenemos la regla del código on demand. Este punto está pensado para que el servidor pueda enviar scripts de código, o en tiempo antaño un objeto de Flash o JAVA, para extender la funcionalidad del cliente. No ahondaremos mucho en este punto porque a final de cuentas, esta es la única regla que es opcional, ya que no todos los sistemas REST aplican este punto, aunque ciertamente con Rails hace uso de esta funcionalidad al permitirnos enviar código de JavaScript como respuesta a una petición.

Ahora que conoces la parte técnica, hablemos de manera más práctica en los siguientes temas.