Должен ли RESTful API предоставлять данные для всей формы?

13

Допустим, у меня есть веб-приложение на JavaScript, которое полностью использует RESTful API для данных.

Допустим, у этого приложения есть форма данных, и предположим, что я редактирую запись в / 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"}
]

Точно так же, если у вас будет список категорий, я бы добавил для этого отдельную конечную точку.

GET / категории:

[
    {"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 / product / new. Скорее, я бы построил форму в вашем приложении для обработки добавления новых продуктов, которая знает соответствующие запросы для заполнения своих списков (например, GET / category, GET / sales_users и т. Д.).

— Дэн Лайонс
источник

3

Предполагая, что список продавцов относительно статичен, я думаю, что вы хотели бы отдельный вызов API /salesusers который вы могли бы вызвать один раз (при загрузке формы и т. Д.) И сохранить, чтобы вам не приходилось повторно запрашивать эти данные каждый время. Помните, что в REST вы организуете свой API вокруг ресурсов, а продавцы логически отделяют ресурсы от продуктов.

Аналогичным образом, при вызове /product/newвы бы хотели отправлять данные только для нового продукта, который может включать идентификатор sales_user, но не более того. Изменения в самом sales_user будут отдельным вызовом.

— Dan1701
источник