Должен ли я использовать заголовок Content-Location таким образом?

Question

Предисловие:

После прочтения много о HTTP и REST, вы провели несколько часов разработки хитрую схему контента переговоров. Чтобы ваш веб-API мог обслуживать XML, JSON и HTML с одного URL-адреса. Потому что, как вы знаете, ресурс должен иметь только один URL-адрес, а другие представления должны запрашиваться с использованием заголовков Accept. Вы начинаете удивляться, почему для этой реализации понадобилось 20 лет.

И вот, когда на самом деле slaps you in the face.

Так, чтобы помочь браузерам (и сами пытаться отлаживать) с помощью вашего обслуживания, чтобы служить желаемому типу контента, вы делаете то, что каждый уважающий себя евангелист из REST презирает вас за: Расширения файлов.

вечные муки в аду несмотря на это, является следующее применение Content-Location + .ext приемлемым?

Скажите, что у нас есть пользователи на /users/:loginname например /users/bob. Это будет конечная точка API для всего, что способно установить правильный заголовок Accept. Но для любого возможного Content-Type (или, по крайней мере, некоторого) мы разрешаем альтернативный метод доступа, и это URL-адрес с суффиксом типа файла. Например, /users/bob.html для представления HTML. Предположим (и это большое предположение, чтобы сделать) логин будет никогда содержать период/точка.

Запрос:

GET /users/bob.json HTTP/1.1 
Host: example.com 

Ответ:

HTTP/1.1 200 OK 
Content-Type: application/json 
Content-Length: 14 
Content-Location: /users/bob 

{"foo": "bar"} 

Это позволит мне кодировать альтернативные способы доступа (в данном случае) информацию о пользователе. Например, ссылка на страницу пользователя может быть <a href="https://stackoverflow.com/users/bob.html">Bob</a>. Ссылка на vCard (чтобы добавить пользователя в адресную книгу/Outlook/все) будет <a href="https://stackoverflow.com/users/bob.vcf">Bob</a>.

Есть ли какие-то подводные камни, которые я пропустил? Какими будут плюсы и минусы этого?

Редактировать: This появилось немного поздно, чтобы я заметил. И даже если это касается предмета, и это действительно полезно, я думаю, что это не совсем то, что я ищу ...

Answer 1

Согласно RFC 2616:

The Content-Location entity-header field MAY be used to supply 
the resource location for the entity enclosed in the message 
when that entity is accessible from a location separate from 
the requested resource's URI. 

и

The Content-Location value is not a replacement for the original 
requested URI; it is only a statement of the location of the resource 
corresponding to this particular entity at the time of the request. 

поэтому, как правило, да, вы можете использовать заголовок Content-Location для определения источника происхождения. Основным недостатком использования суффикса расширения является то, что вы делаете другие URL-адреса, например./users/bob, /users/bob.vfc, /users/bob.html - это три разных ресурса.

Answer 2

Насколько я могу судить, вы используете Content-Location точно так же; он должен указывать на более конкретный URI.