Соглашения об именах REST при использовании с Spring MVC

Question

Я разрабатываю приложение SpringMVC с JPA с базовыми объектами.

Используя это базовое соглашение REST: https://restfulapi.net/resource-naming/ для объекта с именем customer , у меня есть:

HTTP GET http://xxxx/customers  //Get all customers
HTTP POST http://xxxx/customers  //Create new customers
HTTP GET http://xxxx/customers/{id}  //Get customer for given Id
HTTP PUT http://xxxx/customers/{id}  //Update customer  for given Id
HTTP DELETE http://xxxx/customers/{id}  //Delete customer  for given Id

Это довольно просто.Теперь, как следует называть URL-адрес из страниц, вызывающих эти методы?

Например, сначала я хочу показать все значения, используя таблицы данных.

Должен ли я использовать тот же URL-адрес GET http://xxxx/customers а как-то спрашивать представление HTML, а не данные?Пример использования параметра: http://xxxx/customers?view или что-то в этом роде.O Должен ли я использовать полный новый набор или URL-адрес?

То же самое, каким должен быть URL-адрес страницы, на которой отображается только одна запись (например, я щелкнул customer YYY в предыдущемТаблица данных).Должно быть GET: http://xxxx/customers/yyy?view или что-то совершенно новое?

В этом случае с Spring. Если я обнаруживаю параметр view , я отвечаю результатом modelAndView, а если не просто json , включая данные.

Answer 1

Это довольно просто.Теперь, как следует называть URL-адрес со страниц, вызывающих эти методы?

Реальный ответ, как отметил Роман Воттнер, - «все, что вы хотите».

Одна вещья думаю, что это поможет сразу - перестаньте думать о «методах» и подумайте о документах.

HTTP - это протокол приложения, чей домен приложения является передачей документов по сети - Джим Уэббер

Целевые URI для документов это просто: идентификаторы .Вы можете использовать любые соглашения об орфографии, которые вам нравятся, потому что клиентам все равно - во многом так же, как компилятору не важно, какое написание вы используете для имен переменных.

Конечно, еслиэто действительно не имеет значения (и это действительно не имеет значения), тогда использование имен ресурсов в соответствии с обычным «это соглашение для коллекции; это соглашение для элемента коллекции» также хорошо.

Должен ли я использовать тот же URL-адрес GET http://xxxx/customers, но каким-то образом запрашивать представление HTML, а не данные?

Почти при любом вопросе о REST подходящей эвристикой является вопрос "как"мы делали это с веб-браузерами и HTML? "

Основная идея заключается в том, что ресурс (он же" документ ") может иметь много разных представлений.Клиенты могут использовать Accept , чтобы сообщать серверу типы медиа, которые он понимает для данного контекста.

Теперь интересно то, что браузеры будут отправлять различные заголовки Accept дляизображения, чем они будут для JavaScript или страниц.Так как они узнали?Ну, они понимают HTML и поэтому могут различать различные варианты тегов (script, a, img и т. Д.) И выбирают соответствующий заголовок для использования при извлечении каждого.

Другими словами, вы непросто дайте кому-нибудь ссылку - вы также дадите им подсказки, чтобы клиент мог понять семантику ссылки. Веб-ссылки - это общий подход.