RESTful Batch Delete

RESTful Batch Delete
RESTful Batch Delete - ep_petrus @ Unsplash

При пакетном удалении ресурса. Например, удаление всех Заказов, принадлежащих Клиенту 99:

DELETE /customer/99/order

Если существуют определенные бизнес-правила1, которые не позволяют удалять заказы, соответствующие определенным критериям. Например:

  • Заказы, которые были сделаны за последние 7 дней, не могут быть удалены.

У данного клиента 99 есть заказы, которые были сделаны за последние 7 дней.

А заказы старше 7 дней не могут быть удалены

Когда клиент API делает запрос DELETE к /customer/99/order

Тогда как должен выглядеть HTTP-ответ?


Я не уверен, что даже разрешение этого - хорошая идея. (т.е. разрешение частичного успешного удаления).

Если это хорошая идея, вы, вероятно, захотите передать такую информацию, как:

  • Ресурсы, которые были удалены.
  • Ресурсы, которые не были удалены.
  • Причина, по которой конкретный ресурс в коллекции не мог быть удален. Если существует несколько причин, по которым один ресурс не может быть удален, это может привести к путанице.

Какой код статуса вы бы вообще использовали для такого ответа?

И вообще, хорошая ли это идея?


1: There could be any number of these 'rules' that prevent an individual Order from being deleted.

Хорошая ли это идея?

Итак, в конце концов, пакетное удаление заказов на задней стороне - это деталь реализации сервера. Что касается клиента, то он просто попросил вас удалить один ресурс, "заказы" клиентов 99. Вы можете определить это по тому факту, что у него есть один URL customers/99/orders

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

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

Но если вы думаете, что это будет проблемой, когда клиенты будут пытаться удалить заказы, на удаление которых у них нет разрешения из-за бизнес-логики, то более долгосрочным решением будет отразить это в вашей схеме URL, поскольку теперь у вас явно есть два типа заказов, те, которые клиент может удалить, и те, которые клиент не может удалить.

Таким образом, что-то вроде

DELETE customer/99/expired_orders

в котором будут только заказы старше 7 дней, и которые клиент может уверенно удалить, было бы правильным решением. Помните, что схема URL не обязательно должна соответствовать схеме БД 1 к 1.

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

DELETE customer/99/orders?age=expired

LetsCodeIt, 18 января 2023 г., 10:54

Похожие посты

Где я должен создать корень агрегата? В api или во фронтенде?Лучшие практики создания ресурсов с помощью REST-маршрутовМожно ли возвращать разные DTO для одной и той же конечной точки, если пользователь вошел в систему, и если он анонимный?Дополнительные вопросы к старой теме: "Как указать множество идентификаторов и имя их переменных в запросе REST API?"Как назвать конечную точку POST, которая ведет себя как GET?Что мешает приложению использовать хранилище другой платформы бесплатно?Django: Есть ли смысл разделять вызовы api на собственные конечные точки url?Какой уровень журнала следует использовать для ожидаемого, но (потенциально) плохого события?Дополнительные вопросы к старой теме: "Как указать множество идентификаторов и имя их переменных в запросе REST API?"Обработка числового значения, которое может быть конкретным или диапазоном в REST API