Видаліть кілька записів за допомогою REST

Який НАЙБІЛЬШИЙ спосіб видалення декількох елементів?

Моїм випадком використання є те, що у мене є Backbone Collection, де мені потрібно мати можливість видаляти кілька елементів одночасно. Варіанти, здається, такі:

1. Надіслати запит на ВИДАЛЕННЯ для кожного окремого запису (що здається поганою ідеєю, якщо потенційно є десятки елементів);
2. Надіслати ВИДАЛИТИ, де ідентифікатори, які потрібно видалити, нанесені в URL-адресу (тобто, "/ records / 1; 2; 3");
3. Відправте нестандартний об'єкт JSON, що містить ідентифікатори, позначені для видалення.

Всі варіанти менш ніж ідеальні.

Це здається сірою зоною Конвенції REST.

1. Це життєздатний вибір RESTful, але очевидно має обмеження, які ви описали.
2. Не роби цього. Це буде тлумачитися посередниками як таке, що означає “ВИДАЛИТИ (єдиний) ресурс на /records/1;2;3” - Тож відповідь 2xx на це може змусити їх очистити кеш /records/1;2;3; не продувати /records/1, /records/2або /records/3; проксі відповідь 410 на /records/1;2;3або інші речі, які не мають сенсу з вашої точки зору.
3. Цей вибір найкращий, і його можна зробити НАДКІННО. Якщо ви створюєте API і хочете дозволити масові зміни ресурсів, ви можете використовувати REST для цього, але саме те, що багатьом не відразу очевидно. Одним із методів є створення ресурсу "запиту на зміну" (наприклад, шляхом розміщення такого тіла, якrecords=[1,2,3] to /delete-requests) та опитування створеного ресурсу (зазначеного в Locationзаголовку відповіді), щоб з'ясувати, чи ваш запит прийнято, відхилено чи триває або завершив. Це корисно для тривалих операцій. Інший спосіб - надіслати PATCHзапит до ресурсу списку ,/records, основна частина якої містить перелік ресурсів та дій, які потрібно виконати з цими ресурсами (в будь-якому форматі, який ви хочете підтримати). Це корисно для швидких операцій, де код відповіді на запит може вказувати на результат операції.

Все можна досягти, дотримуючись обмежень REST, і зазвичай відповідь полягає в тому, щоб перетворити "проблему" на ресурс і вказати йому URL-адресу.
Отже, пакетні операції, такі як видалення тут, розміщення декількох елементів у списку або внесення однакових змін у сукупність ресурсів, можна виконати, створивши список "пакетних операцій" та розмістивши в ньому нову операцію.

Не забувайте, REST - це не єдиний спосіб вирішити будь-яку проблему. “REST” - це просто архітектурний стиль, і вам не потрібно його дотримуватися (але ви втратите певні переваги Інтернету, якщо цього не зробите). Я пропоную вам переглянути цей список архітектур HTTP API і вибрати той, який вам підходить. Просто усвідомлюйте, що ви втрачаєте, якщо вибираєте іншу архітектуру, і приймайте обґрунтоване рішення на основі вашого випадку використання.

Є кілька поганих відповідей на це запитання щодо Шаблонів для обробки пакетних операцій у веб-сервісах REST? які мають занадто багато голосів, але їх також слід читати.

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

У цьому випадку відповідь на ваше запитання буде DELETE /records?id=1&id=2&id=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

Це здається сірою зоною Конвенції REST.

Так, поки що я зіткнувся лише з одним керівництвом з дизайну REST API, в якому згадуються пакетні операції (наприклад, пакетне видалення): керівництво по розробці API API Google .

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

Спеціальний метод може бути пов'язаний з ресурсом, колекцією або послугою. Він може приймати довільний запит і повертати довільну відповідь, а також підтримує потоковий запит і відповідь. [...] Спеціальні методи повинні використовувати дієслово HTTP POST, оскільки воно має найбільш гнучку семантику [...] Для критично важливих методів може бути корисно надати спеціальні пакетні методи для зменшення накладних витрат на запит .

Отже, ви можете зробити наступне згідно з посібником API Google:

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

... щоб видалити купу елементів вашого ресурсу колекції.

Я дозволив здійснити оптову заміну колекції, наприклад PUT ~/people/123/shoes де основним є колекція.

Це працює для невеликих дочірніх колекцій елементів, де клієнт хоче переглянути елементи та обрізати деякі, а також додати інші, а потім оновити сервер. Вони можуть ПОСТАВИТИ порожню колекцію, щоб видалити всі.

Це означало GET ~/people/123/shoes/9б, що він все ще залишатиметься в кеш-пам'яті, навіть незважаючи на те, що PUT видалив його, але це лише проблема кешування і буде проблемою, якщо хтось інший видалить взуття.

Мої API даних / систем завжди використовують ETags на відміну від терміну дії, тому сервер потрапляє під кожен запит, і мені потрібні правильні заголовки версії / паралельності для мутації даних. Для API, які доступні лише для читання та вирівнюються за переглядом / звітом, я використовую час закінчення терміну дії, щоб зменшити кількість звернень за початком, наприклад, таблиця лідерів може бути корисною протягом 10 хвилин.

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

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

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