Чи повинен API RESTful надавати дані для всієї форми?

13

Скажімо, у мене є веб-додаток JavaScript, який повністю використовує API RESTful для даних.

Скажімо, у цій програмі є форма даних, і скажімо, що я редагую запис за адресою / product / 12345. Створюючи форму, я роблю запит RESTful на / product / 12345 і отримую дані JSON:

{
  "id": 12345,
  "name": "Some Product",
  "active": true,
  "sales_user_id": 27
}

Отже, у моєї форми очевидно може бути випадаючий список для вибору продавця. Мені потрібно заповнити цей список. Звідки беруться дані? Який найпоширеніший підхід?

Чи має сенс зробити це частиною відповіді на запит / product / 12345?

{
  "id": 12345,
  "name": "Some Product",
  "active": true,
  "sales_user_id": 27,
  "sales_users": [
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
  ]
}

А як щодо створення нового запису? Чи повинен мій API також відповідати GET / product / new, із наступним?

{
  "sales_users": [
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
  ],
  "categories": [
    {"id": 1, "name": "Category 1"},
    {"id": 2, "name": "Category 2"},
    {"id": 3, "name": "Category 3"},
    {"id": 4, "name": "Category 4"},
    {"id": 5, "name": "Category 5"}
  ],
  "etc": [ ... ]
}

api rest forms

— Чад Джонсон
джерело

будь ласка, ніколи не використовуйте GET-запит, щоб щось створити. Кінцевою точкою має бути / продукт не / продукт / новий . Щоб створити новий продукт, вам слід надіслати запит PUT до цієї кінцевої точки.

— Керем Байдоган

Це нічого не створює. Це суто запит на наявні дані або шаблон для нової, ще не збереженої записи.

— Чад Джонсон

о, вибачте, зараз я бачу, що ти маєш на увазі. будь-який спосіб кінцевої точки продукту не повинен нести відповідальність за надання шаблонного продукту або списку значень для спадних форм форми створення продукту. як говорить @Dan, просто створіть окремі кінцеві точки та використовуйте заголовки кешування, щоб ваш веб-переглядач міг кешувати спадні значення для продуктивності.

— Керем Байдоган

6

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

GET / sales_users:

[
    {"id": 1, "name": "Anna Graham"},
    {"id": 2, "name": "Dick Mussell"},
    {"id": 3, "name": "Ford Parker"},
    {"id": 4, "name": "Ferris Wheeler"},
    {"id": 5, "name": "Jo King"}
]

Так само, якщо ви будете мати список категорій, я б додав для цього окрему кінцеву точку.

Отримати / категорії:

[
    {"id": 1, "name": "Category 1"},
    {"id": 2, "name": "Category 2"},
    {"id": 3, "name": "Category 3"},
    {"id": 4, "name": "Category 4"},
    {"id": 5, "name": "Category 5"}
]

Я б не будував GET / продукт / новий. Швидше, я б створив форму у вашому додатку для обробки додавання нових продуктів, які знають відповідні запити для заповнення його списків (наприклад, GET / категорії, GET / sales_users тощо).

— Ден Лайонс
джерело

3

Якщо припустити, що список продавців відносно статичний, я б подумав, що вам потрібно окремий дзвінок API, /salesusersякий ви могли б зателефонувати один раз (під час завантаження форми тощо) та зберегти, щоб не потрібно повторно запитувати ці дані час. Пам'ятайте, що в REST ви організовуєте свій API навколо ресурсів, а продавці логічно відокремлюють ресурси від продуктів.

Крім того, під час дзвінка /product/newви хочете лише надсилати дані для нового продукту, який може містити ідентифікатор sales_user, але нічого більше. Зміни самого продавця-продавця будуть окремим дзвінком.

— Dan1701
джерело