Я бы сказал, что Spring HATEOAS не заменяет DTO: он основан на DTO. Таким образом, вы можете сделать свой класс DTO расширенным ResourceSupport
или заключить его в Resource<T>
.
Модели, представляющие домен вашего приложения, и модели, представляющие данные, обрабатываемые вашим API , являются (или, по крайней мере, должны) различными проблемами и должен быть отделен друг от друга. Вы не хотите ломать свои клиенты API, когда добавляете, удаляете или переименовываете поле из модели предметной области приложения.
Пока ваш сервисный уровень работает с моделями домена / персистентности, ваши контроллеры API должны работать с другим набором моделей. Например, по мере развития моделей вашего домена / персистентности для поддержки новых бизнес-требований вы можете захотеть создать новые версии моделей API для поддержки этих изменений. Вы также можете отказаться от старых версий API по мере выпуска новых версий. И это вполне возможно достичь, когда вещи отделены.
Чтобы свести к минимуму стандартный код преобразования модели предметной области в модель API (и наоборот), можно полагаться на такие платформы, как MapStruct . И вы также можете рассмотреть возможность использования Lombok для генерации методов получения, установки, equals()
, hashcode()
и toString()
для вас.