В то время как спецификация HTTP 1.1, кажется, позволяет телам сообщений на запросах DELETE , похоже, это указывает на то, что серверы должны игнорировать его, поскольку для него нет определенной семантики.
4.3 Тело сообщения
Серверу СЛЕДУЕТ читать и пересылать тело сообщения по любому запросу; если метод запроса не включает определенную семантику для тела объекта, то тело сообщения СЛЕДУЕТ игнорировать при обработке запроса.
Я уже рассмотрел несколько связанных обсуждений по этой теме в SO и за ее пределами, например:
- Разрешено ли тело объекта для HTTP-запроса DELETE?
- Полезные данные методов HTTP-запроса
- HTTP GET с телом запроса
Большинство обсуждений, похоже, сходятся во мнении, что предоставление тела сообщения при DELETE может быть разрешено. , но обычно не рекомендуется.
Кроме того, я заметил тенденцию в различных клиентских библиотеках HTTP, где все больше и больше улучшений, похоже, регистрируются для этих библиотек для поддержки тел запросов при DELETE. Большинство библиотек, кажется, подчиняются, хотя иногда и с небольшим начальным сопротивлением.
Мой вариант использования требует добавления некоторых необходимых метаданных в DELETE (например, «причина» удаления, а также некоторые другие метаданные, необходимые для удаления). Я рассмотрел следующие варианты, ни один из которых не кажется полностью подходящим и не соответствует спецификациям HTTP и / или лучшим практикам REST:
- Тело сообщения - спецификация указывает, что тела сообщения при DELETE не имеют семантического значения; не полностью поддерживается HTTP-клиентами; не стандартная практика
- Настраиваемые заголовки HTTP. Требование настраиваемых заголовков обычно противоречит стандартной практике ; их использование несовместимо с остальной частью моего API, ни один из которых не требует настраиваемых заголовков; кроме того, нет хорошего HTTP-ответа, указывающего на неправильные значения настраиваемого заголовка (вероятно, это отдельный вопрос вообще)
- Стандартные заголовки HTTP - стандартные заголовки не подходят
- Параметры запроса - добавление параметров запроса фактически изменяет удаляемый Request-URI; против стандартной практики
- Метод POST - (например
POST /resourceToDelete { deletemetadata }
) POST не является семантическим вариантом удаления; POST фактически представляет собой противоположное желаемое действие (т.е. POST создает подчиненные ресурсы; но мне нужно удалить ресурс) - Множественные методы - разделение запроса DELETE на две операции (например, PUT удалить метаданные, затем DELETE) разбивает атомарную операцию на две, потенциально оставляя несогласованное состояние. Причина удаления (и другие связанные метаданные) не являются частью самого представления ресурса.
Моим первым предпочтением, вероятно, было бы использование тела сообщения, а затем - настраиваемых заголовков HTTP; однако, как указано, у этих подходов есть некоторые недостатки.
Существуют ли какие-либо рекомендации или передовые методы, соответствующие стандартам REST / HTTP, для включения таких необходимых метаданных в запросы DELETE? Есть ли другие альтернативы, которые я не рассматривал?
Jersey
, не допускают тело дляdelete
запросов.