Отображение маршрута Spring Boot REST

Question

Я просто думаю, что лучше всего создавать картографирование PATH для службы отдыха. Допустим, у нас есть следующие пути:

/users POST 
/users/1 PATCH, GET 
/users/1/contacts GET, POST 
/users/1/contacts/1 GET, PATCH 

Вопрос в том - что является лучшей практикой для создания контроллеров. Например, у нас есть UserController, где мы технически можем поместить все эти сопоставления. Или - мы должны создать отдельные контроллеры (UserController, ContactsController). f.e UserController ниже, если мы все поместим.

@RequestMapping("users") 
@RestController 
public class UserController { 

    @RequestMapping(method = RequestMethod.POST) 
    public ResponseEntity<Void> createUser() {} 

    @RequestMapping(method = RequestMethod.GET) 
    public User getUser() {} 

    @RequestMapping(value = "{id}/contacts", method = RequestMethod.GET) 
    public List<Contact> getContacts() {} 

    @RequestMapping(value = "{id}/contacts", method = RequestMethod.POST) 
    public ResponseEntity<Void> createContact() {} 

    ..... 
} 

И если мы создадим отдельные контроллеры, как тогда должны быть организованы пути? Наверное, это глупый вопрос, но я буду рад, если бы кто-то мог поделиться опытом.

Answer 1

Позволяет предположить, что количество объектов, связанных с Пользователем, будет увеличиваться в будущем. Так что очевидно, что лучше разбить его по субъектам:

UserController -> UserService -> UserRepository,

ContactController -> ContactService -> ContactRepository,

FriendshipController -> FriendshipService -> FriendshipRepository

Из моего опыта, Пользовательский контроллер

@RestController 
@RequestMapping("/user") 
public class UserController extends AbstractController { 

... 

    @RequestMapping(method = RequestMethod.POST) 
    public ResponseEntity<?> createUser(@RequestHeader("X-Auth-Token") Optional<String> @RequestBody User user) { 

... 

    @RequestMapping(method = RequestMethod.GET) 
    public ResponseEntity<?> listUsers(@RequestHeader("X-Auth-Token") Optional<String> authToken) { 
... 

связанных с контроллером Дружбы области действий пользователя:

@RestController 
@RequestMapping("/user/{id}") 
public class FriendshipController extends AbstractController { 

... 

@RequestMapping(value = "/friendship/code", method = RequestMethod.POST) 
    public ResponseEntity<?> generateCodeForUser(@PathVariable("id") long id) { 

... 

@RequestMapping(value = "/friendship/code", method = RequestMethod.GET) 
    public ResponseEntity<?> retrieveCodeForUser(@PathVariable("id") long id) { 

... 

Не уверен, что это аксиома, но помочь мне организовать свой код.

Answer 2

Я вентилятор для отдельных контроллеров, поскольку они удаляют связь между Users и Contacts (например) - что, если позже вы хотите использовать Contacts в отдельном контексте? (Т.е.независимо от User они принадлежат)

Если они разделены, пути будут выглядеть очень похоже на то, что у вас есть:

Пользователи

/users GET, POST 
/users/{user-id} PATCH, GET 

Контакты

/contacts GET, POST 
/contacts/{contact-id} GET, PATCH 

Если существует зависимость между Contacts и Users (и в этом случае, похоже, есть один), вы можете иметь это так:

/contacts/for-user/{user-id} GET, POST 
/contacts/for-user/{user-id}/{contact-id} GET, PATCH 

Это позволяет добавлять контакты к другим вещам (а не только пользователей) и пользователей в других контекстах (независимо от их контактов)

Например, пользователи кофеварки

/coffee-maker/users GET 

Или, если кофеварка не удается, кто мы связываемся для ремонта?

/coffee-maker/contacts GET 

Возможно контакт для ремонта кофеварки также пользователя (но они не должны быть)

Еще одна вещь, вы можете повернуть его и сказать, что контакт для устройство (т.е. кофеварка)

/contact/for-appliance/{appliance-id} GET 

Суть в том, что если вы разъединить контакты от пользователей, вы можете назначить контакты с другими лицами, а не не заставляя отношения быть User -> Contacts - если, конечно, вы не не хотят отделять их из-за бизнес-правил или какая-то причина

В любом случае, нужно учитывать, что есть много способов сделать отображение