Представлення упорядкованого списку - одна з найскладніших проблем із реляційними базами даних. Додавання властивості позиції до відношення списку-членства є найпоширенішим способом цього, оскільки ви можете легко отримати впорядкований список, додавши ORDER BY positionдо свого SQL-запиту, і тому що ви можете легко вставити елементи в середину списку шляхом усереднення значення попереднього та наступного члена списку, припускаючи, що позиція є плаваючою, а не цілою.
Слід уникати використання подвійно пов'язаних списків, оскільки легко випадково зробити посилання непослідовними, а в кінцевому підсумку - циклічним графіком або деревом.
Однак API RESTful не страждають від обмежень реляційних баз даних. Ви можете просто зробити щось, що здається природним, а не використовувати хак, як позицію властивості.
Якщо у вас є лише до кількох сотень елементів у списку, просто перенесіть увесь список у запиті. Припускаючи, що ми хочемо змінити порядок того, [1, 2, 3, 4]де члени списку є ідентифікаторами, ми могли б
POST /url/of/the/list
Content-type: application/json
...
[1, 2, 4, 3]
Потім сервер може перенести це на будь-яку технологію бази даних, яку ви використовуєте, але користувачеві API не потрібно враховувати ці деталі.
Якщо список великий і елементи зазвичай запитуються індивідуально, ви можете дозволити індекс у URL-адресі:
GET /page/7
Якщо ви перебуваєте в HATEOAS, відповідь може включати в себе попередні / наступні посилання для спрощення навігації, якщо цей ресурс зазвичай споживається таким чином. Однак це не означає, що ваша база даних також містить цей подвійний список.
Якщо список дуже великий, ви можете розкрити ArrayListподібні операції, такі як insertабо push/ append. Я міг уявити собі такий дзвінок, як
POST /url/of/the/list?at=1357;mode=insert
...
description of the item to insert
Якщо переупорядкування є загальним випадком використання та переупорядкування слід здійснити негайно, то ви можете запропонувати відповідну кінцеву точку у своєму API:
POST /url/of/the/list/reorder-item?from=783;to=1357
Якщо упорядкований список має бути зроблений явно, буде простіше передати новий порядок як документ JSON, див. Вище.
Зараз не зовсім вірно, що ви можете розглядати свій API як повністю окремий від використовуваної технології баз даних. Однак найкраще зберігати зовнішній API максимально вільним від деталей про реалізацію. Якщо будь-яке упорядкування торкається приблизно 30 рядків для оновлення цілого стовпця порядку, це не зайво. Просто робіть найпростішу можливу справу і завжди оновлюйте весь список. Якщо ваш масштаб вимагає вдосконалення використання вашої бази даних, віддавайте перевагу захопленню цієї складності у вихідному середовищі, де легше підтримувати послідовність.