Очень странная операция http delete rest — удаление с большим количеством параметров

#rest #http #uri #restful-url #httpverbs

Вопрос:

Команда анализа работала над некоторыми спецификациями, которые кажутся мне немного странными.

Мне нужно удалить ресурс из таблицы базы данных. У меня есть идентификатор записи в качестве входного параметра.

Это прямая операция удаления http.

 DELETE http://my-url/{id}
 

Они хотят добавить в качестве входных параметров некоторые другие значения, присутствующие в записи, потому что, по их словам, «операция удаления в этом случае очень деликатна, и мы хотим быть уверены, что исключим ошибки во внешнем интерфейсе, переданный идентификатор должен быть идентификатором переданных значений записи».

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

Я знаю, что это не более спокойная операция.

Я изменил вот так:

 DELETE http://my-url/{id}
REQEUST BODY
{
    "myProperty1" = 123,
    "myProperty2" = "VALUE",
    ...
}
 

Поколение чванства злится из-за УДАЛЕНИЯ с ТЕЛОМ ЗАПРОСА.

Я должен переключиться на

  • ПОЧТОВАЯ операция с ТЕЛОМ ЗАПРОСА
  • Операция УДАЛЕНИЯ с некоторыми ПАРАМЕТРАМИ ЗАПРОСА

Команда разработчиков любит как можно дольше оставаться в спокойной обстановке. Что было бы лучше, чтобы не сбиться с ритма?

ЛЮБЫЕ ДРУГИЕ СОВЕТЫ ИЛИ РЕШЕНИЯ, КОТОРЫЕ, КАК МЫ ДУМАЛИ, НЕ БУДУТ ОЦЕНЕНЫ ПО ДОСТОИНСТВУ.

Ответ №1:

Поколение чванства злится из-за УДАЛЕНИЯ с ТЕЛОМ ЗАПРОСА.

Да, все верно.

Полезная нагрузка в сообщении запроса на удаление не имеет определенной семантики — RFC 7231

УДАЛЕНИЕ — это отделение URI от его представлений. Это несколько аналогично удалению ключа из карты/словаря или символической ссылки в файловой системе. Он сообщает веб-серверу прекратить обслуживание определенной веб-страницы.

Обычно легко определить, каким должен быть идентификатор для запроса на УДАЛЕНИЕ; это будет тот же идентификатор, который вы используете для поиска представления с запросом GET.


УДАЛЕНИЕ-это действие с семантикой при передаче документов через сетевой домен.

Обратите внимание, что это замечание включено в стандарт:

Относительно небольшое количество ресурсов позволяет использовать метод УДАЛЕНИЯ-его основное использование предназначено для сред удаленного создания, где у пользователя есть некоторые указания относительно его эффекта.

Если вы пытаетесь передать сообщение на свой сервер с полезной нагрузкой, чтобы сервер мог сделать что-то умное, вам, вероятно, следует использовать POST, а не УДАЛЯТЬ.

Помните: использовать POST — это нормально. Всемирная паутина была катастрофически успешной, используя немногим больше, чем GET и POST.


Они хотят добавить в качестве входных параметров некоторые другие значения, присутствующие в записи, потому что, по их словам, «операция удаления в этом случае очень деликатна, и мы хотим быть уверены, что исключим ошибки во внешнем интерфейсе, переданный идентификатор должен быть идентификатором переданных значений записи».

Возможно, то, что здесь ищется, — это условное удаление. У нас есть стандартизированные заголовки, которые могут использоваться валидаторами для определения соответствия запроса на УДАЛЕНИЕ и текущего состояния ресурса.

Комментарии:

1. Мы согласны. Может быть, мы можем подвести итог: когда вы не можете точно определить это, это сообщение.