Який правильний спосіб зробити складний метод пошуку RESTful?

Дотримуючись принципів REST, я хотів би створити метод GET для свого API, який здійснює пошук за деякими критеріями і повертає результати клієнту. Проблема полягає в тому, що критерії можуть мати до 14 параметрів, один з них - це список складних об'єктів, тому ...

• Я навіть не знаю, чи можна кодувати / декодувати ці складні об'єкти до / з параметрів URL.

• Я не підрахував, скільки часу може отримати URL-адреса, але я впевнений, що вона буде достатньо великою і, можливо, досягне межі довжини URL-адреси?

Також пошук повинен показувати результати в режимі "реального часу", тобто кожен раз, коли користувач щось змінює з форми пошуку, він повинен мати можливість бачити нові результати, не натискаючи жодної кнопки "пошук".

Чи можете ви пояснити мені ці моменти, і що б вам порадили створити спокійний метод пошуку з великою кількістю параметрів?

Перш ніж прочитати мою відповідь, я хотів би сказати, що погодився з @Neil. Треба вибирати наші битви. Зазвичай ми хочемо зробити все можливе, але іноді замало місця для дискусій, і нам доводиться приймати рішення проти нашої волі.

У будь-якому випадку, у відповіді Ніла я пропускаю ще одне. Документація . Просто для того, щоб розробники знали, що POST просить /searchбути безпечними.

Це сказав.

1. Дайте шанс отримати

Розглянемо GETспочатку варіант. Перевірте максимальну довжину URL-адреси цього питання . Оцініть, чи довша ваша найдовша рядок запиту перевищує 2000 символів. Якщо це не так, і ви не очікуєте, що це буде, почніть GET. Це може здатися некрасивим, але принаймні ви можете зробити закладку URL-адреси, і, звичайно, у неї є всі переваги, отримані з семантики методу (ідентифікація, безпека та кешування)

1.1 Спробуйте кодувати рядок запиту

Наприклад, у базі 64. Навіть javascript підтримує базові кодування 64 .

Ось як це працює:

1. Побудуйте JSON з усіма фільтрами та нормалізуйте його.
2. Розбираємо його на рядок
3. Зашифруйте його
4. Відправити закодований JSON як параметр запиту ( /search?q=SGVsbG8gV29ybGQh....).
5. На стороні сервера розшифруйте параметр q .
6. Десеріалізуйте рядок JSON

Попередньо зробіть найдовший можливий рядок JSON, закодуйте його та візьміть довжину. Оцініть, чи відповідає кодований рядок в URL-адресі. Я реалізував наступний фрагмент на Fiddle.js для тестування. (Я сподіваюся, що це все ще працює) ¹

Базові коди 64 є детермінованими та оборотними, тому немає шансів на зіткнення.

За допомогою закодованих запитів ми також могли б зберігати пошукові запити в БД, закладку URL-адреси, спільне використання посилань тощо. І, звичайно, нам не потрібно уникати / не скасовувати рядок.

1.2 Спробуйте з псевдонімами

Читаючи цей блог про те, як створити API REST, я згадав ще одну альтернативу. Псевдоніми для загальних запитів .

Мені це здається цікавим з наступних причин

• Скоротіть довжину рядка запиту. Це робить API більш чистим та зручним для користувачів

  GET / квитки /? Status = closed & closedAt = xxx проти GET / квитки / нещодавно закриті /

• Поєднується з більшою кількістю псевдонімів або більше параметрів запиту.

  GET / квитки /? Статус = закритий та закритийAt = xxx та протягом = 30 хв проти GET / квитки / недавно закриті /? В межах = 30 хв

• Ми можемо комбінувати псевдоніми з кодованими рядками запитів

  GET / квитки /? Статус = закритий та закритийAt = xxx та протягом = 30 хв. Проти GET / квитки / недавно закриті /? Q = SGVsbG8g ...

^{1: Я використовував JSON, але ми могли використати інші формати, як тільки зможемо його дезаріалізувати на стороні сервера.}

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

Просто перейдіть із запитом POST з параметрами, наданими користувачем, щоб отримати необхідну інформацію з бекенда. Я припускаю, що вам не потрібно робити нічого, крім пошуку, тому немає шансів вам вставити цю сторінку. Просто додайте / пошук в кінці своєї URL-адреси, щоб ви не ризикували вступити в конфлікти зі сторінкою / користувачами, яка була б RESTful

Це повністю залежить від вашої моделі API: Як жодного або як дієслова.

Якщо API не існує, можливо, ви захочете отримати наступний список об'єктів:

GET: /api/v1/objects

У цьому випадку вам потрібно надіслати дані як параметри запиту. Отже, ви повинні описати свої параметри як плоский список ключових значень:

GET: /api/v1/objects

key1 : val1
key2.key1 : val 21
key2.key2 : val 22
....

Деякі платформи підтримують користувацький роздільник параметрів (наприклад, Spring MVC), і ви можете конвертувати парами в об'єкт.