REST: обновление нескольких ресурсов с помощью одного запроса. Является ли это стандартом или его следует избегать?

Простой API REST:

GET: items/{id} - возвращает описание элемента с заданным id
PUT: items/{id} - Обновляет или создает элемент с данным идентификатором
DELETE: items/{id} - удаляет элемент с заданным id

Теперь рассматриваемый API-расширение:

GET: items? filter - возвращает все идентификаторы элементов, соответствующие фильтру
PUT: items - обновляет или создает набор элементов, как описано в полезной нагрузке JSON
[[DELETE: items - удаляет список элементов, описанных в полезной нагрузке JSON]] < - Неправильно

Теперь меня интересуют функции утилиты DELETE и PUT, которые можно легко получить с помощью пунктов PUT/DELETE/{id}.

Вопрос: распространено ли предоставление API таким образом?

Альтернатива: В эпоху Single Connection Несколько запросов, выдающих несколько запросов, дешевы и будут работать более атомарно, поскольку изменение либо завершится успешно, либо сработает, но в возрасте NOSQL-базы данных изменение в списке может уже произойти, даже если запрос обрабатывающие матрицы с внутренним сервером или что-то по какой-либо причине.

[ОБНОВЛЕНИЕ]

После рассмотрения веб-стандартов Белого дома и Википедия: примеры REST теперь используется следующий пример API:

Простой API REST:

GET: items/{id} - возвращает описание элемента с заданным id
PUT: items/{id} - Обновляет или создает элемент с данным идентификатором
DELETE: items/{id} - удаляет элемент с заданным id

API верхнего ресурса:

GET: items? filter - возвращает все идентификаторы элементов, соответствующие фильтру
POST: items - обновляет или создает набор элементов, как описано в полезной нагрузке JSON

PUT и DELETE on/items не поддерживаются и запрещены.

Использование POST, похоже, делает трюк как тот, кто создает новые элементы в окружающем ресурсе, не заменяя, а добавляя.

HTTP-семантика POST Считывает:

Расширение базы данных с помощью операции добавления

Если методы PUT потребуют заменить полную коллекцию, чтобы вернуть эквивалентное представление, указанное в HTTP Semantics PUT:

Успешное PUT данного представления предполагает, что последующее GET на том же целевом ресурсе приведет к возврату эквивалентного представления в ответ 200 (OK).

[UPDATE2]

Альтернативой, которая кажется еще более последовательной для аспекта обновления нескольких объектов, по-видимому, является метод PATCH. Разница между PUT и PATCH описана в Draft RFC 5789 как:

Разница между запросами PUT и PATCH отражается в том, как сервер обрабатывает закрытый объект для изменения ресурса, идентифицированного Request-URI. В запросе PUT закрытый объект рассматривается как модифицированная версия ресурса, хранящегося на исходном сервере, и клиент запрашивает замену сохраненной версии. Однако с помощью PATCH закрытый объект содержит набор инструкций, описывающих, как ресурс, находящийся в настоящее время на исходном сервере, должен быть изменен для создания новой версии. Метод PATCH влияет на ресурс, идентифицированный Request-URI, и также может иметь побочные эффекты для других ресурсов; то есть новые ресурсы могут быть созданы или изменены существующими посредством приложения PATCH.

Таким образом, по сравнению с POST, PATCH также может быть лучшей идеей, поскольку PATCH позволяет UPDATE, где POST позволяет только добавлять что-то значение, добавляя без возможности модификации.

Таким образом, POST выглядит неправильно, и нам нужно изменить наш предлагаемый API:

Простой API REST:

GET: items/{id} - возвращает описание элемента с заданным id
PUT: items/{id} - Обновляет или создает элемент с данным идентификатором
DELETE: items/{id} - удаляет элемент с заданным id

API верхнего ресурса:

GET: items? filter - возвращает все идентификаторы элементов, соответствующие фильтру
POST: items - создает один или несколько элементов, как описано в полезной нагрузке JSON
PATCH: items - создает или обновляет один или несколько элементов, как описано в полезной нагрузке JSON.

Ответ 1

Вы можете ПОВТОРИТЬ коллекцию, например.

PATCH /items
[ { id: 1, name: 'foo' }, { id: 2, name: 'bar' } ]

Технически PATCH идентифицирует запись в URL-адресе (т.е. PATCH /items/1, а не в теле запроса, но это похоже на хорошее прагматическое решение.

Поддерживать удаление, создание и обновление в одном вызове, которые не поддерживаются стандартными соглашениями REST. Одна из возможностей - это специальный "пакетный" сервис, который позволяет собирать вызовы вместе:

POST /batch
[
  { method: 'POST', path: '/items', body: { title: 'foo' } },
  { method: 'DELETE', path: '/items/bar' }
]

который возвращает ответ с кодами состояния для каждого встроенного запроса:

[ 200, 403 ]

Не очень стандартный, но я это сделал, и он работает.

Ответ 2

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

В тех примерах в Википедии они также говорят о ресурсах в Plural.