На протяжении многих лет многие люди сомневались в этом, как мы можем видеть в соответствующих вопросах здесь в стороне. Кажется, что принятые ответы варьируются от «обязательно сделайте это» до «это явно неправильное обращение с протоколом». Поскольку многие вопросы были отправлены много лет назад, давайте углубимся в спецификацию HTTP 1.1 от июня 2014 года (RFC 7231). ), чтобы лучше понять, что явно не рекомендуется, а что нет.

Первый предложенный обходной путь:

Во-первых, о ресурсах и самом URI в разделе 2:

Цель HTTP-запроса называется «ресурсом». HTTP не ограничивает характер ресурса; он просто определяет интерфейс, который может использоваться для взаимодействия с ресурсами. Каждый ресурс идентифицируется унифицированным идентификатором ресурса (URI).

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

Что касается вашего первого предложенного обходного пути (DELETE '/path/abc?itemId=1&itemId=2&itemId=3'), мы можем сделать вывод, что не рекомендуется думать о ресурсе как об отдельном документе в вашей коллекции сущностей, и в то же время хорошо, если вы думаете о ресурсе как о самой коллекции сущностей.

Второй предлагаемый обходной путь:

Что касается вашего второго предложенного обходного пути (POST '/path/abc' with body: { ids: [1, 2, 3] }), использование метода POST для удаления может ввести в заблуждение. В разделе Раздел 4.3.3 говорится о POST:

Метод POST запрашивает, чтобы целевой ресурс обрабатывал представление, включенное в запрос, в соответствии с собственной конкретной семантикой ресурса. Например, POST используется для следующих функций (среди прочего): Предоставление блока данных, таких как поля, введенные в HTML-форму, процессу обработки данных; Публикация сообщения на доске объявлений, в группе новостей, в списке рассылки, в блоге или в аналогичной группе статей; Создание нового ресурса, который еще не идентифицирован исходным сервером; и добавление данных к существующему представлению (представлениям) ресурса.

Хотя есть некоторое пространство для интерпретации «среди прочих» функций для POST, это явно противоречит тому факту, что у нас есть метод DELETE для удаления ресурсов, как мы можем видеть в Раздел 4.1:

Метод DELETE удаляет все текущие представления целевого ресурса.

Поэтому лично я настоятельно не рекомендую использовать POST для удаления ресурсов.

Альтернативный обходной путь:

Вдохновленный вашим вторым обходным путем, мы предлагаем еще один:

DELETE '/path/abc' with body: { ids: [1, 2, 3] }

Это почти то же самое, что предложено во втором обходном пути, но вместо этого используется правильный метод HTTP для удаления. Здесь мы приходим к путанице с использованием объекта body в запросе DELETE. Есть много людей, заявляющих, что это недействительно, но давайте придерживаться Раздел 4.3.5 спецификации:

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

Итак, мы можем сделать вывод, что спецификация не запрещает DELETE иметь полезную нагрузку body. К сожалению, некоторые существующие реализации могут отклонить запрос... Но как это влияет на нас сегодня?

Трудно быть уверенным на 100%, но современный запрос, сделанный с помощью fetch, просто не позволяет использовать body для GET и HEAD. Это то, что указано в стандарте Fetch по адресу Раздел 5.3 по пункту 34:

Если какое-либо тело существует и не равно нулю, или inputBody не равно нулю, а метод запроса — GET или HEAD, то генерируется TypeError.

И мы можем подтвердить, что он реализован таким же образом для fetch pollyfill на строка 342.

Заключительные советы:

Поскольку альтернативный обходной путь с DELETE и полезной нагрузкой body допускается спецификацией HTTP и поддерживается всеми современными браузерами с fetch и начиная с IE10 с полифиллом, я рекомендую этот способ для пакетного удаления допустимым и полностью рабочим способом.

Важно понимать, что методы HTTP работают в области «передачи документов по сети», а не в вашей собственной области.

Ваша модель ресурсов — это не ваша модель предметной области, а не ваша модель данных.

Альтернативное написание: REST API — это прикрытие, позволяющее сделать ваш домен похожим на веб-сайт.

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

DELETE /path/abc?itemId=1&itemId=2&itemId=3

Таким образом, в этом HTTP-запросе конкретно говорится: «Применить семантику удаления к документу, описанному /path/abc?itemId=1&itemId=2&itemId=3». Тот факт, что этот документ состоит из трех различных элементов в вашем хранилище длительного пользования, каждый из которых необходимо удалять независимо, является деталями реализации. Частью смысла REST является то, что клиенты изолированы от именно такого рода знаний.

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

Что касается клиента, /path/abc является идентификатором, отличным от /path/abc?itemId=1&itemId=2&itemId=3. Итак, если клиент выполнил GET для /path/abc и получил представление, включающее itemId 1, 2, 3; а затем отправляет описанное вами удаление, он все равно будет иметь в своем собственном кеше представление, которое включает /path/abc после успешного удаления.

Это может быть, а может и не быть тем, чего вы хотите. Если вы используете REST (через HTTP), это то, о чем вы должны думать в своем дизайне.

POST /path/abc

some-useful-payload

Этот метод сообщает клиенту, что мы вносим некоторые (возможно, небезопасные) изменения в /path/abc, и если это удастся, предыдущее представление должно быть аннулировано. Клиент должен повторить свой предыдущий запрос GET /path/abc, чтобы обновить свое предыдущее представление, а не использовать любую более раннюю недействительную копию.

Но по-прежнему не влияет на кешированные копии других ресурсов.

/path/abc/1
/path/abc/2
/path/abc/3

Все они все еще будут находиться в кеше, даже если они были «удалены».

Честно говоря, многим людям все равно, потому что они не думают о том, что клиенты будут кэшировать данные, полученные с веб-сервера. И вы можете добавить метаданные к ответам, отправляемым веб-сервером, чтобы сообщить клиенту (и промежуточным компонентам), что представления не поддерживают кэширование или что результаты можно кэшировать, но их необходимо перепроверять при каждом использовании.

Еще раз: ваша модель ресурсов — это не ваша модель предметной области, а не ваша модель данных. REST API — это другой способ осмысления того, что происходит, а архитектурный стиль REST настроен для решения конкретной проблемы и, следовательно, может не подходить для более простой задачи, которую вы пытаетесь решить.

Это не означает, что я считаю, что каждый должен проектировать свои собственные системы в соответствии с архитектурным стилем REST. REST предназначен для долгоживущих сетевых приложений, охватывающих несколько организаций. Если вы не видите необходимости в ограничениях, не используйте их. Меня это устраивает, если вы не называете результат REST API. У меня нет проблем с системами, которые соответствуют их собственному архитектурному стилю. -- Филдинг, 2008 г.