Is it bad to create different classes for REST request and response?

Question

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

For example:

@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;
} 

I have two problems.

• Creating too many classes and naming them some times made me nuts.
• Some request and response have common fields.

For example: There's two kind of Notice: Email and Notification:

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?

Answer 1

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.

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:

• 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.