Provide means to render simplified JSON representations of PageImpl easily
#3024
Assignees
Labels
Milestone
Comments
odrotbohm
added
in: web
odrotbohm
added a commit
that referenced
this issue
Jan 12, 2024
This commits all necessary infrastructure to produce simplified JSON representation rendering for Page instances to make sure the representations stay stable and do not expose unnecessary implementation details. The support consists of the following elements: - PagedModel, a stripped down variant of the Spring HATEOAS counterpart to produce an equivalent JSON representation but without the hypermedia elements. This allows a gradual migration to Spring HATEOAS if needed. Page instances can be wrapped into PagedModel once and returned from controller methods to create the new, simplified JSON representation. - @EnableSpringDataWeb support now contains a pageSerializationMode attribute set to an enum with two possible values: DIRECT, which is the default for backwards compatibility reasons. It serializes Page instances directly but issues a warning that either the newly introduced support here or the Spring HATEOAS support should be used to avoid accidentally breaking representations. The other value, VIA_DTO causes all PageImpl instances to be rendered being wrapped in a PagedModel automatically by registering a Jackson StdConverter applying the wrapping transparently. Internally, the configuration of @EnableSpringDataWebSupport is translated into a bean definition of a newly introduced type SpringDataWebSettings and wired into the web configuration for consideration within a Jackson module, customizing the serialization for PageImpl. Fixes GH-3024.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As a follow-up to #2987 we're looking into providing a means to easily have
PageImplinstances rendered in a simplified, stable JSON representation when returned from Spring MVC controller methods. Currently,PageImplis serialized as is exposing internals. The representation would also change should we ever need to change the class' API for unrelated reasons.The currently suggested better way is to rather use Spring HATEOAS
PagedModel. While that's the best option overall, it requires an additional dependency and the user to decide for a hypermedia type to render the navigational links properly. This might not be desirable in all cases.As a middle ground, we're going to introduce a Spring Data
PagedModel, that is a structural equivalent of the Spring HATEOAS' one but avoids adding links as navigational elements. The type can then be used in controllers explicitly (throughpage.map(PagedModel::new), or get applied globally by configuring@EnableSpringDataWebSupport(paginationSerializationMode = VIA_DTO). Not enabling that explicitly is going to cause a warning log issued that outlines the dangers of serializingPageImpldirectly and suggesting the better ways of handling the situation (either Spring Data's or Spring HATEOASPagedModel).The text was updated successfully, but these errors were encountered: