REST, Representational State Transfer, es una técnica de arquitectura software para sistemas web. El término se originó en el año 2000, en una tesis doctoral sobre la web escrita por Roy Fielding, uno de los principales autores de la especificación del protocolo HTTP y ha pasado a ser ampliamente utilizado por la comunidad de desarrollo.

En la actualidad se usa el término REST para describir cualquier interfaz web simple que utiliza XML y HTTP. El nombre se basa en que el cliente que accede a una aplicación web va cambiando su estado en función de los enlaces que se van eligiendo (que devuelven representaciones de los recursos accedidos). Este enfoque plantea una aplicación web como una máquina de estados virtual, dónde las transiciones entre los mismos son hiperenlaces.

REST ha sido aplicado para describir la arquitectura Web deseada, ayudar a identificar problemas existentes, comparar soluciones alternativas, y asegurar que el protocolo o viole las restricciones que hacen que la Web funcione correctamente.

Restricciones de REST

 
Cliente-Servidor
La primera restricción que tiene REST está en común con el estilo Cliente-Servidor.
Separar lo que es competencia del cliente y el servidor es el principio de todo. Hay que distinguir lo que concierne al interfaz del usuario del almacenamiento de datos. De esta manera se ayuda a mejorar la portabilidad de la interfaz de usuario a través de múltiples plataformas. Además también se mejora la escalabilidad porque se simplifican las componentes del servidor al no tener que implementar las funcionalidades que van asociadas a la interfaz del usuario. Otro factor importante es que la separación permite a los componentes desarrollarse independientemente.

Sin estado (Stateless)
La segunda restricción está en común con el estilo client-stateless-server.
Cada petición del cliente debe contener toda la información necesaria para que el servidor la comprenda y no necesite mirar ningún dato almacenado previamente sobre el contexto de la comunicación.

Esta restricción mejora la visibilidad, eficiencia y escalabilidad. La visibilidad mejora porque el servidor no tiene que ocuparse de mirar en otros sitios ni realizar más operaciones para comprender la naturaleza de una simple petición. La eficiencia aumenta porque se hace más fácil recuperarse de errores parciales. La escalabilidad se ve también afectada porque al no hacer falta almacenar los estados entre las peticiones, los componentes pueden liberar recursos más rápidamente. Llevado a la práctica, en la URL, utilizando el método GET, solo deberíamos pasar parámetros que indiquen que función y que acción del sistema estamos utilizando, aquí es importante el uso de urls amigables, ej:

http://www.mi_aplicacion.com/nota/nueva

http://www.mi_aplicacion.com/nota/nueva/guardar

Si estamos logueados con un usuario con permisos, esta url debería llevarnos al formulario de edición de una nueva nota, y al hacer click en el botón guardar, nos debería redirigir a la acción guardar, sin pasar ningún dato por GET, todos los datos son pasados por POST.

Caché
Esta tercera restricción la comparte REST con el estilo Client-Cachestateless-Server Style.
Las respuestas a una petición deben poder ser etiquetadas como cacheable o no-cacheable. Si una respuesta es cacheable, entonces al cliente cache se le da permiso para reutilizar la respuesta más tarde si se hace una petición equivalente.

Interfaz uniforme
La principal característica que distingue a REST del resto de estilos de arquitecturas de red es el énfasis de usar una interfaz uniforme entre los componentes. Aplicando los principios de generalidad de la ingeniera del software a los componentes de la interfaz, se simplifica la arquitectura del sistema global y la visibilidad de interacciones se
mejora. Las implementaciones se separan de los servicios que proporcionan, lo que anima al desarrollo independiente.

La desventaja de usar una interfaz uniforme es que degrada la eficiencia porque la información transferida está en una forma estandarizada y no según las necesidades que tenga la aplicación. Un diseño de interfaz que utiliza REST será eficiente con transferencias de datos web (suelen ser datos voluminosos).

Recursos
Los recursos se definen como fuentes de información específica y son muy importantes en REST. Un cliente accede a los recursos que el servidor dispone. Imagine una aplicación empresarial con información de clientes. En este caso, la lista de clientes es un recurso del servidor y para acceder a ellos, se requiere un identificador único (por ejemplo una URI), que es usado por el cliente para referenciarlo y una interfaz de comunicación estandarizada (por ejemplo HTTP). Obviamente, aparte de tener claro el objeto de una acción, se debe tener clara la acción a ejecutar sobre ese objeto. Así pues, una aplicación interactua con los recursos sabiendo su identificador único y la acción a ejecutar sobre este. Por ejemplo: Recurso: Cliente con Id:120. Acción: Borrar, ej:

http://www.mi_aplicacion.com/cliente/borrar/120

Los recursos generalmente son transmitidos entre el servidor y el cliente usando formatos como HTML, XML o JSON. No obstante, los recursos también pueden ser imágenes, texto plano o cualquier otro formato.

Servicios Web REST
No son más que servicios WEB implementados usando HTTP y los principios de REST que comprenden una colección de recursos de acuerdo a los siguientes aspectos:
  – Una URI base para el nombre del servicio: http://www.mi_aplicacion.com/miservicio/
  – El tipo MIME de los datos soportados por el servicio
  – El conjunto de operaciones soportadas.
  – En REST sobre HTTP, lo más normal es tener estas operaciones
      o POST: Crea nuevos recursos. Como retorno, se ofrece el ID automáticamente creado
      o GET: Lista un recurso
      o PUT: Reemplaza un recurso con otro (Útil para el update)
      o DELETE: Elimina un recurso

Entonces por ejemplo si se quisiera eliminar el clente con ID 120 se haría un request a la siguiente URL desde el cliente(navegador):

http://www.mi_aplicacion.com/miservicio/cliente/borrar/120

Nota: Los métodos PUT y DELETE funcionan sobre recursos HTTP, por lo que es necesaria una correcta configuración y direccionamiento para no sobreescribir o borrar ningún recurso del servidor. Lo mejor a mi criterio y como opinión personal es utilizar POST para todo el manejo de datos emulando la elección de los métodos PUT o DELETE a través de GET y su correspondiente condicional en la lógica de la aplicación.

En conclusión, REST es una arquitectura y no un protocolo como SOAP, y se basa en acciones sobre recursos para permitir la interacción de un cliente con un servidor. La implementación sobre HTTP es la más común y ha permitido la creación de otras tecnologías.

En Apache se puede implementar está técnica con mod_rewrite. Mod_rewrite establece reglas de transformación de los URL basado en patrones regulares (explicado en los posts sobre urls amigables).

Para más información sobre cómo utilizar apache y php para obtener urls amigables visitar los posts anteriores de la sección PHP.

Deja un comentario

Desarrollado por AnimacionyWeb     Stats