为REST请求和响应创建不同的类是不是很糟糕？ [英] Is it bad to create different classes for REST request and response?

问题描述

我正在使用Spring Boot项目，作为我的工具，几乎每个API都有请求和响应类。

I'm working in a Spring Boot project, as my implement at the moment, almost for each API I have request and response classes.

例如：

@RequestMapping(value = "/notice", method = RequestMethod.POST)
public AddNoticeResponse addNotice(@Valid @RequestBody AddNoticeRequest){
    Notice notice = ... // creating new notice from AddNoticeRequest
    noticeRepository.save(notice);
    AddNoticeResponse response = ... // creating new response instance from Notice
    return response;
} 

请求和响应类如下所示：

The request and response classes look like:

@Data
@AllArgsConstructor
public class AddNoticeRequest{
    private String subject;
    private String message;
    private Long timeToLive;
}

// Ommiting some annotations for brevity
public class AddNoticeResponse{
    private String subject;
    private String message;
    private Long timeToLive;
    private Date createTime;
    private String creator;
} 

我有两个问题。

• 创建太多的类并将它们命名一段时间让我疯了。


• 一些请求和响应有共同的领域。

例如：有两种通知：电子邮件和通知：

public class Email {
    private String subject;
    private String message;
    private String receiver;
}

那么，我应该使用扩展公共类的内部类还是只放所有的领域分为一类？哪个更好？

So, should I use an inner class that extends the common class or just put all the fields into one class? Which is better?

public class AddNoticeRequest {

    private String subject;
    private String message;

    class Email extends AddNoticeRequest{
        private String receiver;
    }
}

public class AddNoticeRequest{
    private String subject;
    private String message;
    private Long timeToLive;
    private String receiver;
}

然后当客户端执行添加的请求时电子邮件通知，某些字段是否为空？

Then when the client performs a request to add an Email notice, will some fields be null?

推荐答案

使用定制的DTO进行请求和响应将给出从长远来看，你会更灵活。实际上，没有什么能阻止你使用继承和内部类，但我会避免使用它。

Using tailored DTOs for request and response will give you more flexibility in the long run. Actually, nothing prevents you from using inheritance and inner classes, but I would just avoid it.

我已经回答了一个类似的问题这里，重点介绍在REST API中使用DTO而不是持久性实体的好处。下面你会发现这种方法的一些好处：

I already answered a similar question here, highlighting the benefits of using DTOs over persistence entities in REST APIs. Below you'll find a few benefits of this approach:

• DTO可以根据您的需求进行定制只暴露持久性实体的一组属性时很棒。您不需要注释，例如 @XmlTransient 和 @JsonIgnore 以避免某些属性的序列化。


• 通过使用DTO，您将在持久性实体中避免地狱注释，也就是说，您的持久性实体不会因​​非持久性相关注释而膨胀;


• 您将拥有完全控制对创建或更新资源时收到的属性;


• 如果您使用 Swagger 来记录你的REST API，你可以使用 @ApiModel 和 @ApiModelProperty 注释用于记录您的API模型而不会弄乱您的持久性实体;


• 您可以为每个版本的API使用不同的DTO;


• 映射关系时您会有更大的灵活性;


• 您的DTO可以包含 HATEOAS 。这是不应该添加到持久性对象的东西。


• 您可以使用映射框架，例如 MapStruct 将REST API DTO映射到持久性对象。

• DTOs can be tailored to your needs and they are great when exposing only a set of attributes of your persistence entities. You won't need annotations such as @XmlTransient and @JsonIgnore to avoid the serialization of some attributes.
• By using DTOs, you will avoid a hell of annotations in your persistence entities, that is, your persistence entities won't be bloated with non persistence related annotations;
• You will have full control over the attributes you are receiving when creating or updating a resource;
• If you are using Swagger to document your REST API, you can use @ApiModel and @ApiModelProperty annotations to document your API models without messing your persistence entities;
• You can have different DTOs for each version of your API;
• You'll have more flexibility when mapping relationships;
• Your DTOs can have a list of links for HATEOAS. That's the kind of thing that shouldn't be added to persistence objects.
• You can use mapping frameworks such as MapStruct to map your REST API DTOs from/to your persistence objects.

这篇关于为REST请求和响应创建不同的类是不是很糟糕？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！