The concept of REST DTO is very common when we work with REST architectures. In this type of solutions we are publishing REST resources continuously and quickly a very reasonable doubt will come to mind
What do I publish my business objects directly with their properties or publish a DTO (Data Transfer Objects) instead. Many people will tell us that it is better to use DTOs since we only need the properties. For this we will probably use a tool like Modelmapper.
In this way we save an important layer of classes the DTO or Data Transfer Object and we simply delegate to the business objects that can be much more direct to say it in some way. Also these business objects are usually quite stable when defining the properties since they belong to the core of the system. An invoice is always an invoice and has more or less the same information. Up to here everything seems correct. But there are people who tell us again what is worth but that the DTOs are not bad. What is happening, exactly in this type of solution?
REST DTO and JSON
From my point of view both are possible and if we were in a simple example probably the use of business objects would be enough since they would become JSON DTOS. Now, architectures are not always so definitive. On many occasions situations are more complex to say it in some way. In this case, the complexity lies in the fact that the REST architecture that we design is likely to be consumed by a broad set of clients. Not only that, but on many occasions we will not even have awareness of who the consumer is.
REST DTO and immutability
It is in these cases in which to have a REST DTO layer that allows us to add a level of indirection and control which properties and with what name they are published can generate a greater degree of immutability in the REST API, something that we will all always appreciate in the future.
Date update on 2019-03-12. Date published on 2019-03-12. Category: java Author: Oscar olg