4 DTOs by default for Spring REST API?

Question

hello,

I've been looking for something related for a few weeks, but I'm not convinced.

I'm making a RestAPI. And, I know about the DTO.

First, look at the picture above.

The red picture is the part I drew.

Except for the red part, DTO is only mentioned between Controller-Service.

That is, the problem mentions the necessity of using DTO only between Controller-Serve in the example that explains most of the DTO.

But if you dig a little deeper, someone View(Front) - You mention that you need a "separate" DTO used by the Controller.

That means we already need two separate DTOs.

Then next, Now someone says that DTO should be broken down into RequestDTO and ResponseDTO.

Then I have a ControllerRequestDTO that needs to be passed from View to Controller

ServiceRequestDTO that should be passed from Controller to Service

After that, it is transformed into an Entity and after work is done, the returned Entity must be converted into a DTO.

So, ServiceResponseDTO created in Service and passed to Controller

ControllerResponseDTO that should be sent back from Controller to View

I understood that it should be composed of .

But once again, there is very little information about the DTO required by the View-Controller.

ControllerRequestDTO, ControllerResponseDTO, ServiceRequestDTO, ServiceResposeDTO

4 in total.

Am I making it right?

Or are you increasing unnecessary resources?

Answer 1

Software design is not a set of rules to be followed without thinking. Rather, software design is a means to pursue your goals - and different goals may require different means.

So when somebody tells you to create separate DTOs, you should ask (or actually, they should have told you without prompting) why they recommend this, so you can assess whether their goals and circumstances match yours.

Since I am not the person who suggested you create 4 different DTOs, I can only speculate about the goals and circumstances that may have prompted such a recommendation, but I can say with certainty that these goals and circumstances are not universal, and many applications get by just fine with far less DTOs.

Reasons for separate request/response DTOs:

• if fields are read-only, they make sense in the response, but not in a request. Sure, you could simply ignore these fields in the request, but this may surprise the users of your API, and whoever implements the API might accidentally use the field that was intended to be read only. By removing these fields from the request DTO, you remove this ambiguity.

Reasons for same request/response DTOs:

• simplicity
• ease of use (the client can send the DTO he received back to the server)

Reasons for different rest/service DTOs:

• you need to use the same service from different REST controllers, for instance because you have changed the data contract, but need to keep the previous version operational until all API clients have upgraded
• harder to accidentally change the data contract (which would break your API clients)

Reasons for same rest/service DTOs:

• simplicity

As you can see, it depends. But many apps use the same DTO for requests and responses, controllers and services. You should only make additional work for yourself if you see a clear benefit of doing so.