Как правильно рассматривать идемпотентность с точки зрения HTTP DELETE?

Идемпотентность не означает, что запрос не может иметь побочных эффектов (это то, что описывает свойство «безопасный»). Это просто означает, что многократное выполнение одного и того же запроса не приведет к различным или дополнительным побочным эффектам.

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

@MichaelBurr прав насчет идемпотентности и побочных эффектов.

Я считаю, что в данном запросе REST участвуют два состояния: состояние клиента и состояние сервера. REST — это передача этих состояний между сервером и клиентом, так что состояние клиента отображается в подмножество состояния сервера, другими словами, подмножество остается согласованным с сервером. Из-за этой идемпотентности должно означать, что последующие идемпотентные запросы не приведут к тому, что какое-либо состояние будет отличаться от того, которое было бы при однократном выполнении запроса. С первым DELETE вы можете себе представить, что сервер удаляет ресурс и сообщает клиенту, что он также может удалить ресурс (поскольку ресурс «больше не существует»). Теперь оба состояния должны быть идентичными предыдущему, за исключением удаленного элемента. Чтобы клиент делал что-то другое при попытке удалить элемент после того, как он уже был удален, состояние, передаваемое с сервера клиенту, должно содержать другую информацию. Сервер может действовать немного по-другому с информацией о том, что ресурс уже был удален, но как только он отвечает чем-то другим, идемпотентность методов существенно нарушается.

Для идемпотентной функции:

delete(client_state) -> client_state - {item}
delete(delete(client_state)) -> client_state - {item}
delete(client_state) = delete(delete(client_state))

Лучший способ гарантировать эту идемпотентность — если ответ сервера идентичен, что означает, что единственный способ для состояния клиента нарушить идемпотентность — это неопределенность или побочные эффекты в обработке клиентом ответа (что, вероятно, указывает на к некорректной реализации обработки ответа).

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

HTTP-запросы включают методы удаления, поэтому функция может напоминать

delete(client_state) = send_delete(client_state) -> receive_delete(client_state) 
                                                 -> respond_to_delete(informative_state) 
                                                 -> handle_response(informative_state) 
                                                 -> client_state - {item} 

Википедия определяет Idempotence как операцию, которая:

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

Обратите внимание, что они говорят о result операции. Для меня это включает в себя и состояние сервера, и код ответа.

Спецификация HTTP немного расплывчата в этом вопросе. Он определяет, что Методы HTTP являются идемпотентными:

если предполагаемый эффект нескольких идентичных запросов такой же, как и для одного запроса.

Если вы интерпретируете effect как result в определении Википедии, то они означают одно и то же. В любом случае, я сомневаюсь в практической пользе сообщения клиентам о том, что ресурс уже удален.

Заключительный момент: Идемпотентность определяется с точки зрения одного клиента. Как только вы начнете вводить параллельные запросы от других клиентов, все ставки сняты. Вы должны использовать заголовки условного обновления (такие как If-Match-ETag) для решения таких случаев.

Повторяю: вы должны возвращать один и тот же код возврата, независимо от того, был ли ресурс только что удален, был удален по предыдущему запросу или вообще никогда не существовал.