Веб-ревизия и заголовок Accept-Datetime

Я работаю над созданием документации для предстоящего проекта. Одна из особенностей данных, доступных в этом проекте, заключается в том, что она будет пересмотрена (или, по крайней мере, ее большая часть).

Я столкнулся с (как я понимаю, очень новым) HTTP-заголовком Accept-Datetime. Это абсолютно идеально подходит для обеспечения доступа к проверенным данным с использованием существующих интерфейсов.

Мой вопрос в том, что. Какой тип возврата следует использовать для:

  1. Дата, полученная до даты исходных данных (я думаю, может быть, 404 с телом описание ошибки)?
  2. Данные, которые запрашиваются с использованием заголовка, но которые не поддерживают управление версиями (это действительно липкий для меня. Не уверен, лучше ли ошибка или просто нормальные данные)

Изменить: На данный момент во втором случае я предварительно помещаю код 406 - не принимается

7 голосов | спросил major-mann 16 PMpTue, 16 Apr 2013 21:59:47 +040059Tuesday 2013, 21:59:47

1 ответ


1

Таким образом, механизм, описанный в (информационном) RFC 7089, определяет расширение механизма согласования контента, определенного в спецификации HTTP 1.1. Официально поддерживаемые параметры согласования контента сегодня:

  • Принять
  • Accept-Charset
  • Accept-Language
  • User-Agent

Эти заголовки используются для информирования сервера о желании конкретной версии ресурса (например, Accept-Language: de). Спецификация HTTP 1.1 определяет, что сервер может сделать в ответ на попытку запросить тип контента, который он не поддерживает. В этом случае сервер должен ответить 406 (недопустимым) ответом. Согласно спецификации, ответ 406 указывает:

The resource identified by the request is only capable of generating
response entities which have content characteristics not acceptable
according to the accept headers sent in the request.

Что согласуется с пользователем, указав, что им нужна конкретная версия ресурса, но эта версия не существует.

Итак, для вашего первого вопроса (запрос даты до начальной даты) вы должны ответить 406.

Для вашего второго вопроса (что делать с не-версиями ресурсов) у вас есть два варианта относительно значения состояния вашего ресурса в указанное время.

Если вы считаете, что версия без версии не имеет измерения времени, вы можете решить, что либо она всегда преуспевает, либо всегда терпит неудачу (опять же с 406).

Если аргумент «всегда преуспевает», вы можете утверждать, что данные, не поддерживаемые версией, действительны на все время (если они не версии, а затем никогда не изменяются), системное представление состоит в том, что если данные когда-либо существовали, то это всегда существует с самого начала вашей системной вселенной. Например, запрос на неизменяемое свойство, такое как UUID или серийный номер, должен (возможно) всегда иметь успех.

Если аргумент «всегда терпит неудачу с 406», вы можете утверждать, что если пользователь указал конкретную дату, то она ожидает версию этой информации, и поскольку запрашиваемый ресурс не имеет версий, сервер не может удовлетворить запрос и, следовательно, должен генерировать ответ об ошибке.

Я бы защищал подход, который всегда терпит неудачу.

Несколько замечаний:

  1. RFC 7089 является информационным и не гарантированно становится частью формальной спецификации.

  2. Вам следует подумать о добавлении заголовка Vary в свой ответ, чтобы убедиться, что кеширование делает правильные действия с ответами на запросы с ограниченным сроком.

  3. Вы можете выполнить одно и то же поведение, не полагаясь на RFC 7089, работая в рамках ограничений текущей спецификации HTTP и используя общий механизм Accept с настраиваемым медиадиапазоном. Это будет обычай (обычно это не очень хорошо), но RFC 7089 также не является официальным.

ответил Jim Culbert 18 MonEurope/Moscow2017-12-18T18:55:15+03:00Europe/Moscow12bEurope/MoscowMon, 18 Dec 2017 18:55:15 +0300 2017, 18:55:15

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132