Удаление нескольких записей с помощью REST

Что такое REST-ful способ удаления нескольких элементов?

Мой вариант использования заключается в том, что у меня есть Backbone Collection, в которой мне нужно иметь возможность удалять сразу несколько элементов. Возможные варианты:

Отправьте запрос DELETE для каждой отдельной записи (которая кажется плохой идеей, если есть потенциально десятки элементов);
Отправьте DELETE, где идентификатор, который нужно удалить, нарисованы вместе в URL-адресе (т.е. "/records/1; 2; 3" );
В режиме, отличном от REST, отправьте пользовательский объект JSON, содержащий идентификатор, помеченный для удаления.

Все варианты менее идеальны.

Это выглядит как серая область соглашения REST.

Ответ 1

Является жизнеспособным выбором RESTful, но, очевидно, имеет ограничения, которые вы описали.
Не делай этого. Посредники будут понимать, что это означает "УДАЛИТЬ (единственный) ресурс в /records/1;2;3 " - поэтому ответ 2xx на это может привести к тому, что они очистят свой кеш /records/1;2;3; не чистить /records/1, /records/2 или /records/3; прокси ответ 410 для /records/1;2;3 или другие вещи, которые не имеют смысла с вашей точки зрения.
Этот выбор лучший, и его можно сделать ОТДЕЛЬНО. Если вы создаете API и хотите разрешить массовые изменения в ресурсах, вы можете использовать REST для этого, но для многих это не совсем очевидно. Один из способов - создать ресурс запроса на изменение (например, путем размещения тела, такого как records=[1,2,3] в /delete-requests), и опросить созданный ресурс (указанный в заголовке Location ответа), чтобы найти Если ваш запрос был принят, отклонен, выполняется или завершен. Это полезно для длительных операций. Другой способ - отправить запрос PATCH на ресурс списка /records, тело которого содержит список ресурсов и действий, которые необходимо выполнить с этими ресурсами (в любом формате, который вы хотите поддерживать). Это полезно для быстрых операций, когда код ответа на запрос может указывать на результат операции.

Все может быть достигнуто при соблюдении ограничений REST, и обычно ответ состоит в том, чтобы превратить "проблему" в ресурс и дать ему URL.
Таким образом, пакетные операции, такие как удаление здесь, размещение нескольких элементов в списке или внесение одинаковых изменений в ряд ресурсов, могут быть обработаны путем создания списка "пакетных операций" и размещения в нем новой операции POST.

Не забывайте, что REST - не единственный способ решить любую проблему. "ОТДЫХ" - это просто архитектурный стиль, и вам не нужно его придерживаться (но если вы этого не сделаете, вы потеряете определенные преимущества Интернета). Я предлагаю вам посмотреть этот список HTTP API-архитектур и выбрать ту, которая подходит вам. Просто осознайте, что вы потеряете, если выберете другую архитектуру, и примите обоснованное решение в зависимости от вашего варианта использования.

Есть несколько неправильных ответов на этот вопрос о шаблонах для обработки пакетных операций в веб-службах REST? которые имеют слишком много голосов, но должны быть прочитаны тоже.

Ответ 2

Если GET /records?filteringCriteria возвращает массив всех записей, соответствующих критериям, то DELETE /records?filteringCriteria может удалить все такие записи.

В этом случае ответ на ваш вопрос будет DELETE /records?id=1&id=2&id=3.

Ответ 3

Я думаю, что Mozilla Storage Service SyncStorage API v1.5 - это хороший способ удалить несколько записей с помощью REST.

Удаляет всю коллекцию.

DELETE https://<endpoint-url>/storage/<collection>

Удаляет несколько BSO из коллекции одним запросом.

DELETE https://<endpoint-url>/storage/<collection>?ids=<ids>

ids: удаляет BSO из коллекции, чьи идентификаторы находятся в предоставленном списке через запятую. Может быть предоставлено максимум 100 идентификаторов.

Удаляет BSO в заданном месте.

DELETE https://<endpoint-url>/storage/<collection>/<id>

http://moz-services-docs.readthedocs.io/en/latest/storage/apis-1.5.html#api-instructions

Ответ 4

Я разрешил оптовую замену коллекции, например. PUT ~/people/123/shoes, где тело - все представление коллекции.

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

Это означало бы, что GET ~/people/123/shoes/9 все равно останется в кеше, даже если PUT удалил его, но это просто проблема с кешированием и будет проблемой, если какой-либо другой человек удалит ботинок.

Мои API-интерфейсы данных/систем всегда используют ETags, а не время истечения срока действия, поэтому сервер попадает на каждый запрос, и мне нужны правильные заголовки версии / concurrency для изменения данных. Для API, которые доступны только для чтения и просмотра/отчета, я использую время истечения срока действия, чтобы уменьшить количество просмотров по источнику, например. таблица лидеров может быть хорошей в течение 10 минут.

Для гораздо больших коллекций, таких как ~/people, я, как правило, не нуждаюсь в множественном удалении, прецедент обычно не возникает, и поэтому один DELETE отлично работает.

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

Я также разрешаю сторонним разработчикам создавать свои собственные API-интерфейсы, которые потребляют более строгие API-интерфейсы, поскольку часто существуют практичные, допустимые причины для клиентов, почему они не любят строгий дизайн REST API Fielding zealot и для повышения производительности и использования слоев кэша.

Ответ 5

Это похоже на серую область соглашения REST.

Да, до сих пор я сталкивался только с одним руководством по разработке REST API, в котором упоминаются пакетные операции (например, пакетное удаление): руководство по разработке API Google.

В этом руководстве упоминается создание "пользовательских" методов, которые могут быть связаны через ресурс с помощью двоеточия, например, https://service.name/v1/some/resource/name:customVerb, в нем также явно упоминаются пакетные операции в качестве варианта использования.:

Пользовательский метод может быть связан с ресурсом, коллекцией или службой. Он может принимать произвольный запрос и возвращать произвольный ответ, а также поддерживает потоковый запрос и ответ. [...] Пользовательские методы должны использовать глагол HTTP POST, поскольку он обладает наиболее гибкой семантикой. [...] Для методов, критичных к производительности, может быть полезно предоставить пользовательские пакетные методы для сокращения накладных расходов на запрос.

Таким образом, вы можете сделать следующее в соответствии с руководством Google API:

POST /api/path/to/your/collection:batchDelete

... чтобы удалить кучу элементов из вашего ресурса коллекции.

Ответ 6

Если вы хотите отправить более одного параметра в методе DELETE HTTP для RESTAPI, например POST, GET, PUT, попробуйте следующее:

DELETE /app/module/test HTTP/1.1
Host: xxx.xxx.x.xx
ACCESS-TOKEN: xxxxxxxxxxxxxxxxxxxxxxxx
Content-Type: text/plain
Cache-Control: no-cache
Postman-Token: 3eabfb52-fdb2-4b05-aefa-b2fb0c53c247

first_name=name1&last_name=name2&mobile_no=2222222222&[email protected]

каждое значение разделено

& (и подписать)

а Content-Type - это текст/обычный ИЛИ текст по вашему желанию.

Это появится при отправке запроса почтальону.

и я получил ответ от сервера как

И эти ответы пришли с сервера, который выглядел так на почтальоне.

Array
(
    [first_name] => name1
    [last_name] => name2
    [mobile_no] => 2222222222
    [email_id] => [email protected]
)