Un URI está destinado a identificar un recurso .
Recurso se refiere a lo que se está recuperando. En un sitio web, generalmente es una página . En una API REST, normalmente sería una entidad: persona, perfil, widget, foto, etc.
Los encabezados HTTP le dicen al servidor cosas sobre el cliente : no describen nada sobre el recurso en sí, ni proporcionan ayuda para localizar ese recurso.
Por ejemplo:
Accept-Encoding le dice al servidor que el cliente sabe cómo convertir o descomprimir cierto contenido.Accept-Language le dice al servidor que el cliente está en un determinado entorno local y prefiere el contenido en ese entorno local.Authorization le dice al servidor que el cliente cree que está autorizado para acceder a un recurso protegido.
Un tema común con la mayoría de estos encabezados de solicitud es que el servidor no está obligado a cumplirlos. An Accept-Encodingde gzipno garantiza que la respuesta se comprima. Una Accept-Languagede ur-PKes probable que se ignora cuando se golpea un sitio de Estados Unidos, a menos que específicamente apoyan urdu. Y el servidor se reserva el derecho de verificar el Authorizationencabezado y devolver un 401 o 403 de todos modos, si no le gusta lo que ve.
Ninguno de estos encabezados está destinado a cambiar materialmente nada sobre qué recurso proporciona el servidor en respuesta. El Acceptencabezado no es diferente. Si un cliente especifica application/xmly el servidor solo es compatible application/json, entonces el servidor enviará JSON, no XML. Más importante aún, el Acceptencabezado puede especificar varios tipos, en cuyo caso el servidor es libre de devolver lo que prefiera (o ninguno de ellos). Como puede imaginar, esto podría conducir fácilmente a un comportamiento indefinido para el usuario, pero ignoremos eso por el momento.
La intención de un hipervínculo es vincular a una página ; la página es un cierto tipo de recurso. O bien, podría estar justificado en la definición más flexible de simplemente vincular a un recurso, incluso si ese recurso no es una página (tal vez una imagen o un conjunto de datos). Sin embargo, lo que definitivamente no está destinado a hacer es un enlace a una representación específica de un recurso. Eso es para que el cliente y el servidor negocien, y el servidor finalmente decida.
Accept-LanguageEs un ejemplo obvio de por qué podría ser problemático permitir que los hipervínculos controlen los encabezados. Realmente no tiene sentido, si lo piensas. Cada usuario controla su preferencia de idioma; está configurado en el sistema operativo y / o el navegador. El navegador siempre debe enviar el mismo Accept-Language encabezado, independientemente de la página que se visite. Si el servidor admite ese idioma, genial; si no, responderá con el idioma que considere más cercano.
Si esto pudiera cambiarse mediante hipervínculos, los enlaces entrantes podrían forzarlo a ingresar a la versión en chino del sitio, incluso cuando su navegador y sistema operativo no estén configurados para admitir ese idioma. Eso no tiene sentido. Si el sitio admite inglés y su navegador es inglés, debería responder en inglés, sin importar lo que diga el hipervínculo.
Del mismo modo, si su navegador sabe cómo mostrar XML como datos estructurados, y puede buscar XSL para que se vea bonito, pero realmente no sabe qué hacer con JSON que no sea volcarlo como texto sin formato, obligándolos a El contenido JSON a través de un enlace (si tal cosa fuera posible) es un comportamiento agresivo hostil para el usuario. El navegador siempre debe ser el que diga: "Sé cómo mostrar X, pero no Y, así que realmente preferiría que me dieras X".
Puedo entender por qué podría pensar que es lógico permitir que el usuario de un navegador anule esta decisión. Pero la verdad del asunto es que está pensando en algunos casos pequeños como descargar un informe; El 99% de las veces, cuando existe esta opción, el usuario no está calificado o no tiene información suficiente para hacerlo.
Para decirlo de manera ligeramente diferente, imagine que sus padres o abuelos van a descargar un archivo y se les pide que elijan text / csv o text / plain. ¿Es probable que sepan la diferencia? No sé cuál es el tuyo, pero el mío a menudo ni siquiera puede detectar la diferencia entre un anuncio de banner y un mensaje de error, por lo que no hay forma de que puedan tomar esta decisión de manera inteligente. Por otro lado, puede haber un rayo de esperanza si se les dan enlaces separados para descargar un "libro de Excel" o "Solo texto", que para ellos son recursos separados , no solo una representación diferente del mismo recurso, y los URI deberían reflejar eso.
No se puede confiar en que el usuario comprenda que estas dos cosas son en realidad el mismo recurso, pero una representación diferente. Y sin cambiar todo sobre la forma en que funciona la web hoy en día, no podemos asumir nada sobre lo que harán con ese hipervínculo. Pueden hacer clic, o pueden hacer clic con el botón derecho -> "guardar como", o pueden copiarlo y pegarlo en su barra de direcciones, o pueden estar usando un administrador de descargas, o aún pueden estar usando IE6, o pueden podría estar usando una tableta o dispositivo móvil fuera de marca con un navegador patentado ... y en muchos de estos casos, no van a obtener el contenido que desean, porque perderán la parte del hipervínculo que declara el tipo de contenido, o su navegador no lo admitirá.
¿Podría la especificación HTML haber sido diseñada hace 40 años para admitir un atributo de tipo contenido en hipervínculos? Tal vez, aunque como he descrito en los primeros párrafos, hubo fuertes razones en su contra, especialmente durante un tiempo en que el ancho de banda y los recursos del servidor eran escasos y la idea de poder descargar el mismo informe en múltiples formatos (o, francamente , descargando cualquier informe) honestamente no se le había ocurrido a nadie. Pero ciertamente en el mundo de hoy sería una locura intentar agregar algo así a la especificación; rompería completamente la compatibilidad con versiones anteriores y conduciría al temido "comportamiento indefinido" en todos los navegadores existentes.