not everybody can update the roles of a user). password) and the second endpoint would have to be very selective on what properties would accept when updating a user (e.g. If this application didn't take advantage of DTOs, all the properties of the user would be exposed in the first endpoint (e.g. The first endpoint would handle GET requests and return user data, and the second endpoint would accept PUT requests to update these details. Exposing entities through endpoints can become a security issue if we do not carefully handle what properties can be changed through what operations.Īs an example, let's imagine a Java API that exposes user details and accepts user updates through two endpoints. DTOs and Spring Boot APIsĪnother advantage of using DTOs on RESTful APIs written in Java (and on Spring Boot), is that they can help hiding implementation details of domain objects (aka. As one of the most expensive operations in remote applications is the round-trip time between the client and the server, this coarse-grained interface can help improving performance by a great deal.
In this situation, instead of issuing multiple requests to check the current status and latest transactions of our account, the bank could expose an endpoint that returned a DTO summarizing everything. As Martin Fowler defines in his blog, the main reason for using a Data Transfer Object is to batch up what would be multiple remote calls into a single one.įor example, lets say that we were communicating with a RESTful API that exposes our banking account data. DTO, which stands for Data Transfer Object, is a design pattern conceived to reduce the number of calls when working with remote interfaces.