Можем ли мы передать параметры в HTTP DELETE api

Question

У меня есть API, который удаляет ресурс (DELETE / resources / {resourceId})

API выше может только указать нам удалить ресурс. Теперь я хочу расширить API для других случаев использования, таких как создание резервной копии этого ресурса перед удалением или удалением других зависимых ресурсов этого ресурса et c. Я хочу расширить API удаления до этого (DELETE /resources/{resourceId}?backupBeforeDelete=true...)

Хорошо / рекомендуется ли вышеупомянутый API расширения?

Answer 1

Согласно спецификации HTTP , любое HTTP-сообщение может иметь необязательную часть тела и / или заголовка, что означает, что вы можете контролировать в своем внутреннем сервере - что делать (например, посмотреть, что вы сервер получает и условно выполняет вашу операцию), в случае любого HTTP-метода; однако, если вы говорите о дизайне RESTful API , DELETE или любая другая операция должна ссылаться на ресурс конечной точки REST API, который сопоставлен с методом DELETE контроллера, и сервер должен затем выполнить операцию на основе logi c в вашем методе.

DELETE /resources/{resourceId} HTTP/1.1

должно быть в порядке.

Answer 2

Хороший / рекомендуемый вышеупомянутый API расширения?

Вероятно, нет.

HTTP - это (среди прочего) соглашение о семантике сообщения : единое соглашение о том, что означают сообщения .

Основная цель c состоит в том, что, поскольку все имеют одинаковое понимание того, что означают сообщения, мы можем использовать много из компонентов общего назначения (браузеры, обратные прокси и т.д. c).

Когда мы начинаем пытаться улучшить сообщения нестандартными способами, мы теряем преимущества общего интерфейса.

Что касается DELETE, ваш вариант использования сталкивается с проблемой, заключающейся в том, что HTTP не определяет параметризованный DELETE.

Обычное место для размещения параметров в сообщении HTTP находится в теле сообщения. К сожалению ...

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

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

С другой стороны

DELETE /resources/{resourceId}?backupBeforeDelete=true

Проблема состоит в том, что компоненты общего назначения не распознают, что /resources/{resourceId}?backupBeforeDelete=true - это тот же ресурс , что и /resources/{resourceId}. Идентификаторы для двух различаются, и сообщения, отправленные одному, не считаются влияющими на другой.

Правильный ответ для вашего варианта использования - изменить токен метода; правильный стандартный метод для того, что вы здесь пытаетесь сделать, - это POST

POST служит многим полезным целям в HTTP, включая общую цель «это действие не стоит стандартизировать». - Fielding, 2009

Вы должны использовать «реальный» URI для ресурса (тот же, что используется в запросе GET) и вставлять любые параметры, которые вы необходимо в полезную нагрузку.

POST /resources/{resourceId}

backupBeforeDelete=true

Предполагая, что вы используете POST для других действий, «не требующих стандартизации», в запросе должен быть достаточный контекст, чтобы сервер мог различать guish разные варианты использования. В Интернете мы обычно собираем параметры через форму HTML, обычный ответ - включить токен запроса в тело

POST /resources/{resourceId}

action=delete&backupBeforeDelete=true

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

MAGIC_NEW_DELETE /resources/{resourceId}

backupBeforeDelete=true

Это, ведь откуда ПАТЧ ; Дюссо и др. Признали, что семантика исправлений может быть полезна для всех ресурсов, создали документ, описывающий семантику, которую они хотели, и направили этот документ через процесс стандартизации.