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

Я працюю над невеликою клієнтською серверною програмою для збору замовлень. Я хочу це зробити "REST (ful) способом".

Що я хочу зробити:

Зберіть всі замовні лінії (товар і кількість) і відправте повне замовлення на сервер

На даний момент я бачу два варіанти для цього:

1. Надішліть кожну лінію замовлення на сервер: POST qty та product_id

Я насправді не хочу цього робити, тому що хочу обмежити кількість запитів до сервера, тому варіант 2:

2. Зберіть всі замовні лінії та одразу надішліть їх на сервер.

Як слід реалізувати варіант 2? у мене є кілька ідей: загортайте всі порядкові лінії в об’єкт JSON і відправте це на сервер або використовуйте масив для розміщення рядків замовлення.

Чи є гарною ідеєю чи хорошою практикою реалізація варіанту 2, і якщо так, як мені це зробити.

Що таке хороша практика?

Я вважаю, що ще одним правильним способом підходу до цього було б створення іншого ресурсу, який представляє вашу колекцію ресурсів. Наприклад, уявіть, що у нас є кінцева точка, /api/sheep/{id}і ми можемо /api/sheepрозмістити, щоб створити ресурс для овець.

Тепер, якщо ми хочемо підтримати масове створення, ми повинні розглянути новий ресурс flock за адресою /api/flock(або /api/<your-resource>-collectionякщо вам не вистачає кращого змістовного імені). Пам’ятайте, що ресурси не потрібно відображати у вашій базі даних чи моделях додатків . Це поширена помилка.

Ресурси - це представлення вищого рівня, не пов'язане з вашими даними. Операція на ресурсі може мати значні побічні ефекти, такі як запуск попередження для користувача, оновлення інших пов’язаних даних, ініціювання тривалого процесу тощо. Наприклад, ми можемо відобразити файлову систему або навіть команду unix psяк API REST.

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

Хоча масові операції (наприклад, створення пакетів) є важливими для багатьох систем, вони формально не вирішені стилем архітектури RESTful.

Я виявив, що POSTing колекції, як ви запропонували, в основному працює, але проблеми виникають, коли вам потрібно повідомити про помилки у відповідь на такий запит. Такі проблеми є ще гіршими, коли трапляються численні збої з різних причин або коли сервер не підтримує транзакції. Моя вам пропозиція полягає в тому, що якщо немає проблем з продуктивністю, наприклад, коли постачальник послуг знаходиться в локальній мережі (не WAN) або даних порівняно мало, варто надіслати 100 серверів POST на сервер. Нехай це буде просто, почніть з окремих запитів, і якщо у вас є проблеми з продуктивністю, спробуйте оптимізувати.

Facebook пояснює, як це зробити: https://developers.facebook.com/docs/graph-api/making-multiple-requests

Прості пакетні запити

Пакетний API приймає масив логічних запитів HTTP, представлених як масиви JSON - кожен запит має метод (відповідний методу HTTP GET / PUT / POST / DELETE тощо), rela_url (частина URL після graph.facebook. com), необов'язковий масив заголовків (що відповідає заголовкам HTTP) та необов'язкове тіло (для запитів POST та PUT). Пакетний API повертає масив логічних відповідей HTTP, представлених як масиви JSON - у кожній відповіді є код статусу, необов'язковий масив заголовків та необов'язкове тіло (що є кодованим рядком JSON).

Ваша ідея здається мені справедливою. Реалізація - це питання ваших уподобань. Ви можете використовувати JSON або просто параметри для цього ("order_lines []" масив) і зробити

POST /orders

Оскільки ви збираєтесь створити більше ресурсів одразу за одну дію (порядок та її рядки), важливо перевірити кожен із них та зберегти їх лише у тому випадку, якщо всі вони проходять перевірку, тобто. ви повинні робити це в операції.

Я думаю, що краще надсилати окремі запити в межах одного з'єднання . Звичайно, ваш веб-сервер повинен підтримувати його

Я фактично боровся з цим останнім часом, і ось над чим я працюю.

Якщо POST, який додає кілька ресурсів, успішний, поверніть 200 ОК (я розглядав 201, але в кінцевому підсумку користувач не приземляється на створений ресурс) разом зі сторінкою, на якій відображаються всі додані ресурси, читання -тільки або редагована мода. Наприклад, користувач може вибрати та розмістити декілька зображень у галереї, використовуючи форму, що містить лише один вхідний файл. Якщо POST-запит успішно виконаний, користувачеві надається набір форм для кожного створеного представлення ресурсу зображення, що дозволяє їм задавати більше деталей щодо кожного (ім'я, опис тощо).

У випадку, якщо один або більше ресурсів не вдасться створити, обробник POST припиняє всю обробку і додає кожне окреме повідомлення про помилку до масиву. Потім повертається конфлікт 419, і користувач перенаправляється на сторінку помилки 419 Conflict, яка представляє вміст масиву помилок, а також зворотний шлях до форми, що була подана.

Ви не хочете надсилати заголовки HTTP на 100 рядків замовлення. Ви не хочете генерувати більше запитів, ніж потрібно.

Відправити все замовлення в одному об’єкті JSON на сервер на: сервер / замовлення або сервер / замовлення / новий. Поверніть щось, що вказує на: server / order / order_id

Також розгляньте можливість використання CREATE PUT замість POST