Resources Redux

Es fácil pensar en un recurso web como un archivo en el sistema de archivos de un servidor web, pensando a lo largo de estas líneas, esto no respeta la verdadera capacidad de la abstracción de recursos. Muchas páginas web requieren recursos físicos en un sistema de archivos JavaScript, imágenes, y hojas de estilo. Sin embargo, los consumidores y usuarios de la web no le dan mucha importancia a esos recursos de fondo. En lugar de eso se preocupan por que puedan interactuar con los recursos, y lo más importante es que ellos puedan nombrar los recursos, recursos como:

• Los libros de receta para hacer postres

• Los resultados de la búsqueda “Represa de Guatapé”

• Historia médica del paciente 1811

Todos esos recursos son los tipos de recursos que construimos al redor de las aplicaciones, y el tema común en esto es como cada ítem es lo suficiente importante para identificar y nombrar. Si podemos identificar un recurso, también podemos darle al recurso una URL para que alguien pueda localizarlo. Mediante una URL puedes localizar un recurso, por supuesto, pero también puedes entregar la dirección URL a alguien más mediante la incorporación de la dirección URL en un hipervínculo o enviandolo en un correo electrónico. Pero, a la vez hay muchas cosas que no puedes hacer con una dirección URL. Más bien, hay muchas cosas que una dirección URL no podría hacer. Por ejemplo, una URL no podría restringir a un cliente o servidor a que utilice un tipo específico de tecnología. Todo está basado en HTTP. No importa si tu cliente es C++ y tu aplicación web está en Ruby. A su vez una URL no puede forzar al servidor para almacenar un recurso utilizando cualquier tecnología en particular. El recurso podría ser un documento en el sistema de archivos, o derivar el recurso desde la hora actual del día.

Una URL ni siquiera puede especificar la representación de un recurso específico, un recurso puede tener múltiples representaciones. Un cliente puede solicitar una representación particular usando encabezados en el mensaje de petición HTTP. Un cliente puede solicitar un lenguaje específico, o un tipo de contenido específico. Por ejemplo si trabajamos con aplicaciones web que permitan la negociación del contenido, podríamos ver la flexibilidad de recursos en acción. JavaScript puede solicitar los datos del paciente 1811 en formato JSON, C# puede solicitar el mismo recurso en formato XML y el buscador puede solicitar los datos en formato HTML. Todos ellos trabajan con el mismo recurso, pero usando tres representaciones diferente. Hay una cosa más que una URL no puede hacer, no puede decir que es lo que desea hacer un usuario con un recurso. Una URL no dice si yo quiero recuperar o editar un recurso. Es el trabajo del mensaje de petición HTTP describir esta intención usando uno de los métodos estándar de HTTP, incluyendo GET, POST, PUT, y eliminar.