Как обеспечить, чтобы HTTP-клиент использовал условные запросы на обновления? - PullRequest
3 голосов
/ 26 сентября 2011

В (правильном RMM уровне 3) RESTful HTTP API я хочу обеспечить тот факт, что клиенты должны делать условные запросы при обновлении ресурсов, чтобы избежать проблемы потерянного обновления . Каким будет соответствующий ответ для возврата клиентам, которые неправильно пытаются выполнить безусловные запросы PUT?

Замечу, что (отменено?) mod_atom возвращает 405 Method Not Allowed с заголовком Allow, установленным в GET, HEAD ( просмотр источника ) при попытке безусловного обновления , Это кажется немного вводящим в заблуждение - для меня это означает, что PUT никогда не является допустимым методом для попытки использования ресурса. Возможно, в ответе просто необходим объект сущности, объясняющий, что If-Match или If-Unmodified-Since должны использоваться для того, чтобы сделать запрос PUT условным, в таком случае он будет разрешен?

Или, возможно, 400 Bad Request с подходящим объяснением в теле сущности будет лучшим решением? Но опять же, это не совсем правильно, потому что он использует ответ 400 для нарушения семантики, специфичной для приложения, когда RFC 2616 говорит (мой акцент):

Сервер не смог понять запрос из-за неправильного синтаксиса .

Но, опять же, я думаю, что использование 400 Bad Request для специфической семантики приложения становится широко принятым прагматическим решением (необходима цитата!), И я просто чрезмерно педантичен.

Ответы [ 3 ]

6 голосов
/ 01 октября 2011

После запроса Яна о разъяснении 27 сентября 2011 года рабочая группа HTTPbis опубликовала новый Интернет-проект 18 октября 2011 года с совершенно новым428 Precondition Required статус, специально для разрешения ситуации, описанной в моем вопросе.

По состоянию на апрель 2012 года этот документ теперь публикуется как RFC 6585 (Дополнительные коды состояния HTTP - обновление RFC 2616 (HTTP / 1.1)).Полная цитата раздел 3 :

428 Требуется предварительное условие

Код состояния 428 указывает, что исходный сервер требует, чтобы запрос былусловный.

Его типичное использование - избежать проблемы «потерянного обновления», когда клиент получает состояние ресурса, изменяет его и помещает обратно на сервер, когда тем временем третья сторона изменила состояние насервер, ведущий к конфликту.Требуя, чтобы запросы были условными, сервер может гарантировать, что клиенты работают с правильными копиями.

Ответы, использующие этот код состояния, ДОЛЖНЫ объяснить, как успешно повторно отправить запрос.Например:

HTTP/1.1 428 Precondition Required
Content-Type: text/html

<html>
   <head>
      <title>Precondition Required</title>
   </head>
   <body>
      <h1>Precondition Required</h1>
      <p>This request is required to be conditional;
      try using "If-Match".</p>
   </body>
</html>

Ответы с кодом состояния 428 НЕ ДОЛЖНЫ храниться в кэше.

До введения этого нового кода состояния, Джулиан Решке (член рабочей группы HTTPbis) рекомендовал , используя 403 Forbidden для ситуации, которая теперь охватывается 428.

3 голосов
/ 27 сентября 2011

Насколько мне известно, это не правильно определено.

Я попросил разъяснений: http://lists.w3.org/Archives/Public/ietf-http-wg/2011JulSep/0515.html

2 голосов
/ 26 сентября 2011

Если ваш протокол использует безусловные PUT для создания ресурсов, то я бы интерпретировал безусловный PUT как создание, а не обновление. Поскольку ресурс уже существует, я верну любую ошибку, которую вы вернете в этом случае. (409 Конфликт?)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...