Тот же/другой объект DTO в создании, обновлении и получении конечных точек отдыха?

Question

Рассмотрите следующие классы UserDTO и UserController, которые предоставляют конечные точки для создания, обновления и получения пользователя.

Наличие свойства id в классе UserDTO не имеет смысла для создания и обновления. Если я использую swagger или другую автоматическую сгенерированную документацию API, тогда это показывает, что идентификатор может быть передан в конечной точке создания. Но система не использует его, поскольку идентификаторы генерируются внутри.

Если я посмотрю на get, возможно, я смогу избавиться от свойства id, но это обязательно необходимо в конечной точке пользователя списка.

Я думал о возврате внутреннего объекта пользовательского домена в конечных точках get/list. Таким образом, я могу избавиться от класса id формы UserDTO.

Есть ли лучший вариант, который я могу использовать для этого?

public class UserDTO { 
    private int id; 
    private String name; 

    public int getId() { 
     return id; 
    } 

    public void setId(int id) { 
     this.id = id; 
    } 

    public String getName() { 
     return name; 
    } 

    public void setName(String name) { 
     this.name = name; 
    } 
} 

@RestController 
@RequestMapping(value = "/users", produces = MediaType.APPLICATION_JSON_VALUE) 
public class UserController { 
    @RequestMapping(method = RequestMethod.POST) 
    @ResponseBody 
    public ResponseEntity<Void> create(@RequestBody UserDTO user) { 
    } 

    @RequestMapping(value = "{id}", method = RequestMethod.GET) 
    @ResponseBody 
    public ResponseEntity<UserDTO> get(@PathVariable("id") int id) { 
    } 

    @RequestMapping(value = "{id}", method = RequestMethod.PUT) 
    @ResponseBody 
    public ResponseEntity<Void> update(@PathVariable("id") int id, @RequestBody UserDTO user) { 
    } 
} 

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

Answer 1

Что о создании двух различных интерфейсов:

interface UserDTO { 

    public String getName(); 

    public void setName (String name); 

} 

interface IdentifiableUserDTO extends UserDTO { 

    public Long getId(); 

    public void setId (Long id); 

} 


class DefaultUserDTO implements IdentifiableUserDTO { 

} 

, а затем использовать интерфейс в контроллере вместо класса DTO:

@RestController 
@RequestMapping(value = "/users", produces = MediaType.APPLICATION_JSON_VALUE) 
public class UserController { 
    @RequestMapping(method = RequestMethod.POST) 
    @ResponseBody 
    public ResponseEntity<Void> create(@RequestBody IdentifiableUserDTO user) { 
    } 

    @RequestMapping(value = "{id}", method = RequestMethod.GET) 
    @ResponseBody 
    public ResponseEntity<UserDTO> get(@PathVariable("id") int id) { 
    } 

    @RequestMapping(value = "{id}", method = RequestMethod.PUT) 
    @ResponseBody 
    public ResponseEntity<Void> update(@PathVariable("id") int id, @RequestBody UserDTO user) { 
    } 
} 

Answer 2

Data Transfer Object (DTO) представляет собой модель, которая была создана с очень четко определенная цель: передавать данные на удаленные интерфейсы, точно так же как веб-сервисы. Эта модель очень хорошо подходит в API REST, а DTO предоставит вам больше гибкость в конечном итоге.

Я бы рекомендовал использовать индивидуальные классы для ваших конечных точек, как только представления ресурсов REST не должны иметь те же атрибуты, что и объекты персистентности.

Чтобы избежать кода шаблона, вы можете использовать фреймворки отображения, такие как MapStruct, для сопоставления DTO API REST API с объектами персистентности.

Для получения дополнительной информации о преимуществах использования DTOs в REST API, проверьте следующие ответы:

• Why you should use DTOs in your REST API
• Using tailored classes of request and response

Чтобы дать вашему DTOS лучших имена, проверьте следующий ответ:

• Giving meaningful names to your DTOs