CODEWITHSUNDEEP
javarest
meobeo173
meobeo173

Reputation: 647

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

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.

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?

Upvotes: 17

Views: 12611

Answers (3)

cassiomolin
cassiomolin

Reputation: 130887

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.

Upvotes: 25

Zebronix_777
Zebronix_777

Reputation: 355

I will suggest you to use JSON format instead of creating class and returning its instance every time. But still if you need a class hierarchy you can create a class and put a variable which will store JSON.

Upvotes: 0

Lee
Lee

Reputation: 738

Don't subclass the req/resp objects.

Use an auto de/serialiser like Jackson in your frame work to convert message payloads into business object.

However, you will still end up with a large number of business objects.

Upvotes: 1

Related Questions