为什么要在REST API中使用DTO
DTO代表d ATA 牛逼转让（BOT）Ø bject。
创建此模式的目的非常明确：将数据传输到远程接口，就像Web服务一样。这种模式非常适合REST API ，从长远来看，DTO将为你提供更大的灵活性。
该代表的车型领域的应用代表了和模型通过你的API处理的数据是（或者至少应该是）不同的关注点，应该去耦彼此。在应用程序域模型中添加，删除或重命名字段时，你不想破坏API客户端。
当你的服务层在域/持久性模型上运行时，你的API控制器应在一组不同的模型上运行。例如，随着域/持久性模型的发展以支持新的业务需求，你可能希望创建API模型的新版本以支持这些更改。随着新版本的发布，你可能还想弃用旧版本的API。当事物分离时，这是完全有可能实现的。
仅提及公开DTO而不是持久性模型的一些好处：
- 将持久性模型与API模型分离。
- DTO可以根据你的需求进行定制，当仅公开持久性实体的一组属性时，它们非常有用。你将不需要诸如@XmlTransient和的注释，@JsonIgnore以避免某些属性的序列化。
- 通过使用DTO，你将避免在持久性实体中出现批注，也就是说，持久性实体不会因与持久性无关的批注而肿。
- 在创建或更新资源时，你将完全控制要接收的属性。
- 如果使用的是Swagger，则可以使用@ApiModel和@ApiModelProperty注释来记录你的API模型，而不会弄乱你的持久性实体。
- 你可以为每个API版本使用不同的DTO。
- 映射关系时，你将具有更大的灵活性。
- 你可以为不同的媒体类型使用不同的DTO。
- 你的DTO可以具有HATEOAS的链接列表。那种事情不应该添加到持久性对象中。使用Spring HATEOAS时，你可以扩展DTO类RepresentationModel（以前称为ResourceSupport）或将其包装EntityModel（以前称为Resource
）。
处理样板代码
你无需手动将持久性实体映射到DTO，反之亦然。有很多映射框架，你可以用它来做到这一点。例如，看看基于注释的MapStruct，它可以作为Maven注释处理器使用。它在CDI和基于Spring的应用程序中都能很好地工作。
你可能还需要考虑龙目岛生成getter，setter方法，equals()，hashpre()并toString()为你的方法。
