@GetMapping(path = "/account/{id}", version = "1.1")
public Account get() { ... }

RestClient client = RestClient.builder()
    .baseUrl("http://localhost:8080")
    .apiVersionInserter(ApiVersionInserter.useHeader("API-Version"))
    .build();

// И дальше только версия
client.get().uri("/account/1")
    .apiVersion(1.1)
    .retrieve()
    .body(Account.class);

«ORM — это Вьетнам нашей индустрии»

Джефф перечислил 6 путей, которыми индустрия пыталась сбежать от этого несоответствия:

1. Выбросить объекты. Забить на rich-domain подход и возвращать проекции/tuple’ы. Нет объектов ⇒ нет mismatch’а. Практично, как бы цинично это ни звучало.

2. Перейти к "объектным" хранилищам. OODBMS вроде db4o пытались хранить объекты как есть. Идея жила недолго, но как попытка — эпохальная.

3. Писать маппинг руками. JDBC/JOOQ и полный контроль. Иногда это даже предпочтительнее: больно, но честно.

4. Принять ограничения ORM. Hibernate-путь: 70–80% задач закрываем ORM, остальное — raw SQL. Звучит разумно, если не забывать про кэш и согласованность.

5. Встроить реляционность в язык. LINQ, Scala, F#. Красиво, но массовым это так и не стало.

6. Сделать сами объекты реляционными. RowSet/DataSet-подходы. Интересная идея, но нишевая.

Почему объекты превращались в null и почему классы «не находились» — я не знаю.

Несмотря на то, что с валидацией мы напрямую работаем не часто, имейте в виду, что Spring Boot и ваши @RestController-ы под капотом всё равно используют hibernate-validator. Поэтому почитайте, не поленитесь 😉.