Um URI destina-se a identificar um recurso .
Recurso refere-se à coisa real que está sendo recuperada. Em um site, normalmente é uma página . Em uma API REST, normalmente seria uma entidade - pessoa, perfil, widget, foto etc.
Os cabeçalhos HTTP informam o servidor sobre o cliente - eles não descrevem nada sobre o recurso em si, nem fornecem qualquer ajuda para localizar esse recurso.
Por exemplo:
Accept-Encoding informa ao servidor que o cliente sabe como converter ou descompactar determinado conteúdo.Accept-Language informa ao servidor que o cliente está em um determinado local e prefere conteúdo nesse local.Authorization informa ao servidor que o cliente acha que está autorizado a acessar um recurso protegido.
Um tema comum com a maioria desses cabeçalhos de solicitação é que o servidor não é obrigado a honrá-los. Um Accept-Encodingdos gzipnão garante que a resposta será compactada. Um Accept-Languagedos ur-PKprovavelmente será ignorado ao acessar um site nos EUA, a menos que eles suportem especificamente o Urdu. E o servidor se reserva o direito de verificar o Authorizationcabeçalho e retornar um 401 ou 403 de qualquer maneira, se não gostar do que vê.
Nenhum desses cabeçalhos pretende alterar materialmente qualquer recurso sobre o qual o servidor fornece em resposta. O Acceptcabeçalho não é diferente. Se um cliente especificar application/xmle o servidor suportar apenas application/json, o servidor enviará JSON - não XML. Mais importante, o Acceptcabeçalho pode especificar vários tipos; nesse caso, o servidor está livre para retornar o que preferir (ou nenhum deles). Como você pode imaginar, isso pode facilmente levar a um comportamento indefinido para o usuário, mas vamos ignorá-lo por enquanto.
A intenção de um hiperlink é vincular a uma página - a página sendo um determinado tipo de recurso. Ou você pode ser justificado na definição mais vaga de simplesmente vincular a um recurso, mesmo se esse recurso for algo diferente de uma página (talvez uma imagem ou um conjunto de dados). O que definitivamente não se destina a fazer, no entanto, é o link para uma representação específica de um recurso. Isso é para o cliente e o servidor negociarem e o servidor finalmente decidir.
Accept-Languageé um exemplo óbvio de por que pode ser problemático permitir que hiperlinks controlem cabeçalhos. Realmente não faz sentido, se você pensar sobre isso. Cada usuário controla sua própria preferência de idioma; está configurado no sistema operacional e / ou no navegador. O navegador sempre deve enviar o mesmo Accept-Language cabeçalho, independentemente da página que está sendo visitada. Se o servidor suportar esse idioma, ótimo; caso contrário, responderá com o idioma que achar mais próximo.
Se isso puder ser alterado por hiperlinks, os links de entrada poderão forçá-lo a entrar na versão em chinês do site, mesmo quando o navegador e o sistema operacional não estiverem configurados para oferecer suporte a esse idioma. Isso não faz sentido. Se o site suportar inglês e seu navegador for inglês, ele deverá responder em inglês, independentemente do link indicado.
Da mesma forma, se o seu navegador souber exibir XML como dados estruturados e puder procurar XSLs para torná-lo bonito, mas não souber realmente o que fazer com o JSON, a não ser despejá-lo como texto simples, forçando-o a O conteúdo JSON por meio de um link (se isso fosse possível) é um comportamento agressivamente hostil ao usuário. O navegador deve sempre dizer: "Eu sei como exibir X, mas não Y, então eu realmente preferiria que você me desse X".
Entendo por que você pode pensar que é lógico permitir que o usuário de um navegador substitua essa decisão. Mas a verdade é que você está pensando em alguns casos minúsculos como baixar um relatório; 99% do tempo, quando essa opção existe, o usuário não está qualificado ou não possui informações suficientes para fazê-lo.
Em outras palavras, imagine seus pais ou avós fazendo o download de um arquivo e sendo solicitados a escolher text / csv ou text / plain. Eles provavelmente sabem a diferença? Não conheço o seu, mas o meu geralmente nem consegue identificar a diferença entre um banner e uma mensagem de erro, portanto não há como eles fazerem essa escolha de maneira inteligente. Por outro lado, pode haver um vislumbre de esperança se eles receberem links separados para baixar uma "pasta de trabalho do Excel" ou "Somente texto" - que, para eles, são realmente recursos separados , não apenas uma representação diferente do mesmo recurso, e os URIs devem refletir isso.
Não se pode confiar no usuário para entender que essas duas coisas são na verdade o mesmo recurso, mas uma representação diferente. E sem alterar tudo sobre o modo como a web funciona hoje, não podemos assumir nada sobre o que eles farão com esse hiperlink. Eles podem clicar ou clicar com o botão direito do mouse -> "salvar como" ou copiar e colar na barra de endereços ou usar um gerenciador de downloads ou ainda usar o IE6 ou pode estar usando algum tablet ou dispositivo móvel fora da marca com um navegador proprietário ... e em muitos desses casos, eles não obterão o conteúdo que desejam, porque perderão a parte do hiperlink que declara o tipo de conteúdo ou o navegador não será compatível.
A especificação HTML poderia ter sido projetada há 40 anos para oferecer suporte a um atributo de tipo de conteúdo em hiperlinks? Talvez, embora, como descrevi nos primeiros parágrafos, houvesse fortes razões contra isso, especialmente durante um período em que a largura de banda e os recursos do servidor eram escassos e a ideia de poder baixar o mesmo relatório em vários formatos (ou, francamente , baixar qualquer relatório) honestamente não havia ocorrido a ninguém. Mas certamente no mundo de hoje seria insano tentar adicionar algo assim às especificações; quebraria completamente a compatibilidade com versões anteriores e levaria ao temido "comportamento indefinido" em todos os navegadores existentes.