Какой код статуса HTTP используется для отклонения PUT из-за оптимистического отказа блокировки

Question

Предположим, что я хотел бы реализовать некоторую оптимистичную блокировку и использовать ETags, чтобы указать наиболее актуальное состояние ресурса. Это означает, что клиенты будут использовать заголовок If-Match, когда PUT ting для обновления.

В соответствии с HTTP spec сервер должен вернуть 412 Precondition failed, если ETag для заголовка If-Match не соответствует текущему состоянию ресурса.

Однако 409 Conflict, по-видимому, ближе к тому, что я хочу выразить семантически, тем более что он дает рекомендации относительно того, что включить в ответ.

Неправильно ли возвращать 409 в случае несоответствия ETag, предоставленного в заголовке If-Match?

Answer 1

С вашей ссылки на спецификации:

Если ни один из матча объектные метки, или если «*» дается и не текущий объект не существует, сервер НЕ ДОЛЖЕН выполнять запрошенный метод, и должен возвращать ответ 412 (предварительный отказ). Такое поведение наиболее полезно, когда клиент хочет предотвратить изменение способа обновления, такого как PUT, от изменения ресурса, который был изменен с момента последнего получения клиентом.

Поскольку спецификация требует HTTP 412 (действительно, она использует «ДОЛЖНА»), и, поскольку ясно, что они учитывают именно используемый вариант использования, HTTP 412 кажется правильным кодом ответа.

412 все равно разумно. В запросе указано, что обновление выполняется условно. 412 говорит, что условие не удалось, поэтому служба не будет этого делать. Тем более, что 412 - хорошее соответствие концепции условных запросов; 409, казалось бы, привязаны к определенному виду отказа, который может быть или не быть условным по своему характеру. Например, я мог видеть, что служба возвращает 409 в ответ на безусловный запрос POST-сообщения с внутренним конфликтом.

Но увидеть следующее, а также из спецификации:

10.4.10 409 Конфликт

Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса. Этот код разрешен только в ситуациях, когда ожидается, что пользователь сможет разрешить конфликт и повторно отправить запрос. Тело ответа ДОЛЖНО включать достаточную информацию, чтобы пользователь мог распознать источник конфликта. В идеальном случае объект ответа будет содержать достаточную информацию для пользователя или агента пользователя для устранения проблемы; однако это может быть невозможно и не требуется.

Конфликты, скорее всего, возникнут в ответ на запрос PUT. Например, если использовалось управление версиями, а объект PUT включал изменения в ресурс, который конфликтует с теми, которые были сделаны с помощью более раннего (стороннего) запроса, сервер может использовать ответ 409, чтобы указать, что он не может выполнить запрос , В этом случае объект ответа, скорее всего, будет содержать список различий между двумя версиями в формате, определяемом ответом Content-Type.

Как бы то ни было, спецификация требует 412 в контексте условного запроса, предполагая, что конфликт версий является ключевым драйвером для 409s.Возможно, 409 будет использоваться там, где конфликт версий происходит как часть безусловного запроса.