Я провел небольшое исследование и выяснил, что Spring Data Rest использует собственный модуль Джексона для десериализации JSON в сущности JPA: он использует класс PersistentEntityJackson2Module
и внутренний класс UriStringDeserializer
для разрешения конкретных сущностей из ссылок URI сущностей, http://localhost:8080/post/33
в вашем примере.
Проблема в том, что эта пользовательская десериализация запускается только тогда, когда запускается «стандартная десериализация» Джексона: та, которая использует пустой конструктор, затем использует сеттеры для разрешения и установки полей. В этот момент UriStringDeserializer
преобразует строку в конкретную сущность - Post
экземпляр вашего примера.
Когда вы используете класс данных, у класса нет ни пустого конструктора, ни сеттера, поэтому в BeanDeserializer#deserializeFromObject
методе Джексона он переходит в if (_nonStandardCreation)
, будучи истинным, оттуда вызов переходит в BeanDeserializerBase#deserializeFromObjectUsingNonDefault
, но не передается PersistentEntityJackson2Module
больше, и напрямую завершается ошибкой из-за несоответствия типов между аргументом конструктора и значением json.
Похоже, вам нужно создать запрос функции для его реализации. Если вы решите реализовать себя, предоставление _delegateDeserializer
для BeanDeserializer может быть началом (не уверен).
Однако я не знаю, как сам JPA в первую очередь играет с классами данных - в конце концов, он отслеживает изменения состояния сущности, но у класса данных не может быть изменений состояния. Таким образом, в конце концов, возможно, не удастся использовать классы данных - лучше помнить.
Примечание: Вы, вероятно, не можете просто расширить / переопределить PersistentEntityJackson2Module
, поскольку оно зарегистрировано для нескольких компонентов в RepositoryRestMvcConfiguration