DELETE

Метод DELETE запрашивает, чтобы сервер происхождения удалил ассоциацию между целевым ресурсом и его текущей функциональностью. По сути, этот метод похож на команду rm в UNIX: он выражает операцию удаления отображения URI сервера происхождения, а не ожидание, что ранее связанная информация будет удалена.

Если целевой ресурс имеет одно или несколько текущих представлений, они могут быть или не быть уничтожены сервером происхождения, а связанное с ними хранилище может быть или не быть восстановлено, что полностью зависит от природы ресурса и его реализации сервером происхождения (что выходит за рамки данной спецификации). Аналогичным образом, в результате DELETE может потребоваться деактивация или архивация других аспектов реализации ресурса, например, соединений с базой данных или шлюзом. В общем случае предполагается, что сервер происхождения разрешает DELETE только для тех ресурсов, для которых у него есть предписанный механизм выполнения удаления.

Очень немногие ресурсы допускают метод DELETE - он используется в основном в удаленных средах авторинга, где пользователь имеет определенные указания относительно его действия. Например, ресурс, который ранее был создан с помощью запроса PUT или идентифицирован по полю заголовка Location после ответа 201 (Created) на запрос POST, может позволить соответствующему запросу DELETE отменить эти действия. Аналогичным образом, пользовательские реализации пользовательских агентов, реализующие функцию авторизации, например клиенты контроля ревизий, использующие HTTP для удаленных операций, могут использовать DELETE, основываясь на предположении, что пространство URI сервера было создано для соответствия хранилищу версий.

Если метод DELETE успешно применен, исходный сервер ДОЛЖЕН отправить код состояния 202 (Accepted), если действие, вероятно, будет успешным, но еще не выполнено, код состояния 204 (No Content), если действие выполнено и не требуется предоставление дополнительной информации, или код состояния 200 (OK), если действие выполнено и ответное сообщение содержит представление, описывающее статус.

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

Ответы на метод DELETE не подлежат кэшированию. Если запрос DELETE проходит через кэш, в котором есть один или несколько сохраненных ответов для эффективного URI запроса, эти сохраненные ответы будут аннулированы (см. раздел 4.4 в [RFC7234]).