Почему заголовок HTTP-местоположения установлен только для запросов POST /201 (Создано)?
На мгновение игнорируя ответы 3xx, мне интересно, почему заголовок HTTP-местоположения используется только в сочетании с запросами POST /201 (Создано) ответов.
Для 201 (Создано) ответов, Местоположение - это то, что нового ресурса, который был создан запросом.
Это широко поддерживаемое поведение, но почему его не следует использовать с другими методами HTTP? Возьмем спецификацию JSON API в качестве примера:
Он определяет собственную ссылку на текущий ресурс внутри полезной нагрузки JSON ( не редкость для API RESTful). Эта ссылка включена в каждую полезную нагрузку. В спецификации сказано, что вы ДОЛЖНЫ включить заголовок HTTP-местоположения, если вы создаете новый документ с помощью POST и что значение совпадает с самоссылающейся ссылкой в полезной нагрузке, но это необходимо ТОЛЬКО для POST. Зачем использовать пользовательский формат для ссылки на себя, если вы можете просто использовать заголовок HTTP-местоположения?
Примечание. Это не относится к JSON API. То же самое для HAL, JSON Hyper-Schema или других стандартов.
Примечание 2. Он даже не относится к заголовку HTTP-местоположения, так же как и заголовок HTTP-ссылки. Как вы можете видеть, JSON API, HAL и JSON Hyper-Schema не только определяют соглашения для самоссылающихся ссылок, но и для выражения информации о связанных ресурсах или возможных действиях для ресурса. Но похоже, что все они могут просто использовать заголовок HTTP-ссылки. (Они могут даже поместить ссылку на себя в заголовок ссылки HTTP, если они не хотят использовать заголовок расположения HTTP.)
Я не хочу ругать, просто кажется, что это что-то вроде "изобретать велосипед". Это также кажется очень ограничивающим фактором: если вы просто используете заголовок HTTP / заголовок ссылки, не имеет значения, запрашиваете ли вы JSON, XML или что-то еще в заголовке HTTP accept, и вы получите полезную мета-информацию о вашем ресурсе на запрос HEAD, который не будет содержать ссылки, если вы будете использовать JSON API, HAL или JSON Hyper-Schema.
2 ответа
Семантика Location Заголовок - это не ссылка, ссылающаяся на себя, а ссылка, которой должен следовать пользовательский агент для выполнения запроса. Это имеет смысл в перенаправлениях, и когда вы создаете новый ресурс, который будет находиться в новом месте, вам следует перейти на него. Если ваш запрос уже выполнен, то есть у вас уже есть полное представление нужного вам ресурса, возвращать Location,
Link заголовок может считаться семантически эквивалентным гипертекстовой ссылке, но его следует использовать для ссылки на метаданные, относящиеся к данному ресурсу, когда тип носителя не поддерживает гипермедиа, поэтому он не заменяет функциональность ссылки на связанные ресурсы в RESTful API.
Потребность в настраиваемом формате ссылки в представлении ресурса связана с необходимостью отделения ресурса от базовой реализации и протокола. REST не связан с HTTP, и можно использовать любой протокол, для которого существует допустимая схема URI. Если вы решили использовать Link заголовок для всех ссылок, вы подключаетесь к HTTP.
Допустим, вы предоставляете ссылку FTP для клиентов, чтобы следовать. Где будет Link в таком случае?
Семантика заголовка Location зависит от кода состояния. Для 201 он ссылается на вновь созданный ресурс, но в запросах 3xx он может иметь несколько (хотя и схожих) значений. Я думаю, именно поэтому его обычно избегают для других целей.
Альтернативой является заголовок Content-Location, который всегда имеет непротиворечивое значение. Он сообщает клиенту канонический URL-адрес запрашиваемого им ресурса. Это чисто информативно (в отличие от Местоположения, которое, как ожидается, будет обработано клиентом).
Таким образом, заголовок Content-Location, похоже, больше напоминает ссылку на себя. Однако Content-Location также не имеет определенного поведения для PUT и POST. Это также, кажется, довольно редко используется.
Это сообщение в блоге Location vs Content-Location - хорошее сравнение. Вот цитата:
Наконец, ни один заголовок не предназначен для общего назначения ссылок.
В целом, требование стандартизированной, само-связи в теле кажется хорошей идеей. Это позволяет избежать путаницы на стороне клиента.