HTTP/La arquitectura de la Web/El protocolo visible

Hasta ahora nos hemos centrado en lo que una URL no puede hacer, ahora centrémonos en lo que un URL puede hacer. O más bien, centremonos en lo que una URL y HTTP pueden hacer, porque trabajan muy bien juntos.

En su trabajo, Fielding describe los beneficios de embarcar HTTP. Estos beneficios comprenden la escalabilidad, simplicidad, fiabilidad y el bajo acoplamiento. HTTP ofrece esos beneficios en parte para que puedas pensar en una URL como un puntero, o una unidad de “indirection” (habilidad para referenciar algo usando un nombre, referencia, entre otros) entre un cliente y una aplicación de servidor. Una vez más la propia URL no dicta una representación específica de los recursos, la implementación de la tecnología o la intención del cliente. En lugar de eso, un cliente puede expresar la intención que desea y la representación en un mensaje HTTP.

Un mensaje HTTP es un simple mensaje de texto sin formato. Lo encantador del mensaje HTTP es como tanto la solicitud como la respuesta son totalmente autodescriptivas. Una solicitud incluye el método HTTP (lo que el cliente quiere hacer), la ruta de acceso al equipo, y adicional cabeceras que aportan información acerca de la representación deseada. Una respuesta incluye un código de estado para indicar el resultado de transacción, pero también incluyes cabeceras con instrucciones de caché, el tipo de contenido del recurso, el tamaño del recurso, y posiblemente otros valiosos metadatos.

Porque toda la información solicitada por una transacción está contenida en los mensajes, y porque la información es visible y fácil de analizar, las aplicaciones HTTP pueden confiar en un número de servicios que proporcionan valor como un mensaje se mueve entre la aplicación del cliente y la aplicación del servidor.