REST DELETE действительно идемпотент?

Question

DELETE считается идемпотентом.

Если УДАЛИТЬ http://example.com/account/123, это приведет к удалению учетной записи.

Если я сделаю это снова, я бы ожидал 404, поскольку аккаунт больше не существует? Что если я попытаюсь УДАЛИТЬ учетную запись, которой никогда не было?

Answer 1

Идемпотентность относится к состоянию системы после завершения запроса

Во всех случаях (кроме ошибок - см. Ниже), учетная запись больше не существует,

С здесь

"Методы также могут иметь свойство" идемпотентности "в этом ( помимо ошибок или проблем с истечением срока действия )побочные эффекты от N> 0 идентичных запросов такие же, как и для одного запроса. Методы GET, HEAD, PUT и DELETE разделяют это свойство. Кроме того, методы OPTIONS и TRACE НЕ ДОЛЖНЫ иметь побочные эффекты, и поэтому по своей природе идемпотентны. "

Ключевой бит, к которому относятся побочных эффектов от N> 0 идентичных запросов, такой же, как и для одного запроса.

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

Answer 2

Идемпотент касается эффекта запроса, а не кода ответа, который вы получаете.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2 говорит:

Методы также могут иметь свойство "идемпотентности", заключающееся в том, что (кроме ошибок с ошибками или истечением срока действия) побочные эффекты от N> 0 идентичных запросов такие же, как и для одного запроса.

Пока выможет получить другой код ответа, эффект отправки N + 1 запросов DELETE на один и тот же ресурс можно считать одинаковым.

Answer 3

Из HTTP RFC :

Методы также могут обладать свойством "идемпотентности" в том, что (помимо ошибок или проблем с истечением срока действия) побочные эффекты N>0 идентичных запросов - это то же самое, что и для одного запроса.

Обратите внимание, что это "побочные эффекты", а не "ответ".

Answer 4

Важным отличием является то, что идемпотент относится к побочным эффектам , а не всем -эффектам или реакциям.Если вы наберете DELETE http://example.com/account/123, то это значит, что учетная запись 123 теперь удалена с сервера.Это единственный эффект, единственный и единственный меняет на состояние сервера.Теперь предположим, что вы делаете тот же самый запрос DELETE http://example.com/account/123 снова, сервер будет отвечать по-другому, но его состояние будет таким же.

Не похоже, что запрос DELETE решил изменить состояние сервера другим способом, потому что учетная запись отсутствовала, например, была удалена другая учетная запись или оставлен журнал ошибок.Нет, вы могли бы вызывать один и тот же запрос DELETE миллион раз, и вы можете быть уверены, что сервер находится в том же состоянии, в котором он был в первый раз, когда вы его называли .

Answer 5

Да. Независимо от кода ответа.

С последний RFC для HTTP 1.1 (выделено мое):

Идемпотентные методы различаются, потому что запрос может быть повторяется автоматически, если сбой связи происходит до клиент может прочитать ответ сервера. Например, если клиент отправляет запрос PUT и основное соединение закрывается до получения какого-либо ответа клиент может установить новый соединение и повторите запрос идемпотента. Оно знает что повторяет запрос будет иметь тот же предполагаемый эффект, даже если оригинал запрос выполнен, , хотя ответ может отличаться.

В нем прямо сказано, что ответ может отличаться. Что еще более важно, он указывает на причину концепции: если действие идемпотентно, клиент может повторить действие, когда он сталкивается с какой-либо ошибкой, и знает, что при этом он ничего не потерпит; в противном случае клиент должен будет сделать дополнительный запрос (возможно, GET), чтобы проверить, эффективен ли предыдущий запрос, прежде чем безопасно повторить действие. Пока сервер может дать такую ​​гарантию, действие идемпотентно. Цитата еще один комментарий :

Вычисление идемпотентности - это надежность системы. Поскольку что-то может выйти из строя (например, сбой в сети), когда вы обнаружите сбой, как вы будете восстанавливаться? Самое простое восстановление состоит в том, чтобы просто сделать это снова, но это работает, только если сделать это снова идемпотентно. Например. discard(x) идемпотент, но pop() нет. Все дело в восстановлении после ошибок.

Answer 6

Я думаю, что то же самое, 404. Учетная запись не существует.

Вы можете поспорить, 400 - Плохой запрос.Но в смысле REST объект, который вы запрашивали для выполнения действия, не существует.Это означает 404.