RESTful способ создания нескольких элементов в одном запросе

Я полагаю, это метод HTTP POST. Не существует такой вещи, как метод CREATE HTTP.

Нет? Ой, подождите, не было. Вместо этого были PUT.

Зачем вам использовать PUT для создания контента? Именно для этого и предназначен метод HTTP POST.

Вы используете PUT для создания ресурсов, когда хотите, чтобы клиент указывал URI ресурса, как в webdav. Я не согласен с использованием плаката PUT, но он имеет место при создании ресурсов, хотя это место может быть ограничено по объему.

@thecoshman, я думаю, он имеет в виду, что он изменяет коллекцию через PUT, но это должно заменить все ресурсы (а не добавлять ресурсы). Таким образом, используя ту же логику, мы должны вместо этого использовать PATCH, учитывая, что мы частично изменяем коллекцию, добавляя новые ресурсы.

@MhdSyrwan Нет, это совершенно новый порядок, нет существующего порядка для «PATCH», поэтому следует использовать либо PUT, либо POST. В этом случае ваш URL-адрес будет похож на /orders, вам все равно, какой URL-адрес назначен каждому отдельному заказу, поэтому POST будет выбором. Теперь, возможно, да, он модифицирует всю коллекцию заказов, однако «заказы» - это не единственный ресурс, и по этой логике можно утверждать, что все является частью корневого ресурса.

Примечание: POST-запрос объекта должен привести к тому, что объект станет подчиненным по отношению к ресурсу, указанному в запросе, и не будет идемпотентным. PUT заменяет объект по адресу и является идемпотентным. Идемпотентность (слово?) - важное ожидание потребителей.

Вы сами нашли решение ошибок при дозировании? Отправка 100 почтовых запросов по мобильному соединению для отображения стыков страницы - плохая идея.

Я добавляю ошибки в массив, перенаправляю пользователя на страницу с ошибкой 419 Conflict (и возвращаю эту ошибку клиенту) и отображаю массив ошибок. См. Мой ответ ниже для более подробной информации.

Это нонсенс. Речь идет об отправке заказа на многие товары, которые, как многие говорили, вы можете просто в сущности одного запроса POST. Другое дело, как сервер обрабатывает это. В этом случае я не вижу проблем с созданием заказа, заполнением того, что вы можете для этого заказа, а также заполнением деталей, которые не могли быть выполнены. Таким образом, пользователь может увидеть свой заказ и увидеть, что все, кроме N товаров, были добавлены в заказ, но некоторые из них отсутствуют на складе или система не знает, что с ними делать. Еще один более простой, но менее удобный вариант - отклонить все

@thecoshman сильно изменился за 3,25 года. Вероятно, вам стоит опубликовать полностью сформулированный ответ на вопрос.

@dlamblin да, мне, наверное, нужно сделать много вещей ... Я доберусь до этого на каком-то этапе, может быть ...

Есть несколько сценариев, в которых я могу подумать, что POST-публикация коллекции более эффективна. Например, если вы предоставляете веб-интерфейс CRUD для добавления списка продуктов (SKU, описание, цена за единицу) с помощью HandsOnTable (библиотека электронных таблиц JS), в этом случае пользователь ожидает просто скопировать / вставить пакет или большую часть продукты сразу. Вы, конечно, можете справиться с этим с помощью JS-клиента и сделать 1 запрос за раз, но это усложняется IMO, я лично предпочитаю оставить эту работу бэкэнд-REST API.

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

Это действительно способ сделать это Facebook, не обязательно RESTful, как попросил OP.

Я думаю, что пакетный API (от Google, Facebook и т. д. - @PuneetArora) более полезен при группировании нескольких несвязанных запросов вместе. Создание запроса, который создает один элемент, а затем группирование всех этих запросов вместе для отправки коллекции элементов - это «безумие» (Эйнштейн). Просто создайте запрос, который передает коллекцию элементов.

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

Это правильный подход. Это не нарушает запрос на сбор POST. Поскольку он используется для публикации одного объекта. Отправка массового запроса с использованием «отдельного массового объекта» - правильный подход.

Мне так нравится, как вы называете конечную точку api с помощью овец и отар! С некоторой степенью абстракции он почти имеет библейскую ссылку: «У меня есть другие овцы, которые не из этого загона; Я должен также привести их, и они услышат Мой голос; и станут одним стадом с одним пастырем». Иоанна 10:16.

Интересно, что люди рекомендуют использовать форму множественного числа (коллекции) в URL-адресе, когда вы хотите создать один ресурс, например: отправить POST в / api / books для создания книги. Но затем, когда вы хотите создать 100 книг (в одном запросе как json), по какому URL-адресу вы разместите коллекцию из 100 книг? вот где начинается беспокойство.

@ code4kix вы можете использовать /api/book-group, /api/book-collection или что-то подобное.