1. Preface
1.1. Migrating to Spring HATEOAS 1.0
For 1.0 we took the chance to re-evaluate some of the design and package structure choices we had made for the 0.x branch. There had been an incredible amount of feedback on it and the major version bump seemed to be the most natural place to refactor those.
1.1.1. The changes
The biggest changes in package structure were driven by the introduction of a hypermedia type registration API to support additional media types in Spring HATEOAS.
This lead to the clear separation of client and server APIs (packages named respectively) as well as media type implementations in the package mediatype
.
The easiest way to get your code base upgraded to the new API is by using the migration script. Before we jump to that, here are the changes at a quick glance.
Representation models
The ResourceSupport
/Resource
/Resources
/PagedResources
group of classes never really felt appropriately named.
After all, these types do not actually manifest resources but rather representation models that can be enriched with hypermedia information and affordances.
Here’s how new names map to the old ones:
-
ResourceSupport
is nowRepresentationModel
-
Resource
is nowEntityModel
-
Resources
is nowCollectionModel
-
PagedResources
is nowPagedModel
Consequently, ResourceAssembler
has been renamed to RepresentationModelAssembler
and its methods toResource(…)
and toResources(…)
have been renamed to toModel(…)
and toCollectionModel(…)
respectively.
Also the name changes have been reflected in the classes contained in TypeReferences
.
-
RepresentationModel.getLinks()
now exposes aLinks
instance (over aList<Link>
) as that exposes additional API to concatenate and merge differentLinks
instances using various strategies. Also it has been turned into a self-bound generic type to allow the methods that add links to the instance return the instance itself. -
The
LinkDiscoverer
API has been moved to theclient
package. -
The
LinkBuilder
andEntityLinks
APIs have been moved to theserver
package. -
ControllerLinkBuilder
has been moved intoserver.mvc
and deprecated to be replaced byWebMvcLinkBuilder
. -
RelProvider
has been renamed toLinkRelationProvider
and returnsLinkRelation
instances instead ofString
s. -
VndError
has been moved to themediatype.vnderror
package.
1.1.2. The migration script
You can find a script to run from your application root that will update all import statements and static method references to Spring HATEOAS types that moved in our source code repository. Simply download that, run it from your project root. By default it will inspect all Java source files and replace the legacy Spring HATEOAS type references with the new ones.
$ ./migrate-to-1.0.sh
Migrating Spring HATEOAS references to 1.0 for files : *.java
Adapting ./src/main/java/…
…
Done!
Note that the script will not necessarily be able to entirely fix all changes, but it should cover the most important refactorings.
Now verify the changes made to the files in your favorite Git client and commit as appropriate. In case you find method or type references unmigrated, please open a ticket in out issue tracker.
1.1.3. Migrating from 1.0 M3 to 1.0 RC1
-
Link.andAffordance(…)
taking Affordance details have been moved toAffordances
. To manually build upAffordance
instances now useAffordances.of(link).afford(…)
. Also note the newAffordanceBuilder
type exposed fromAffordances
for fluent usage. See Affordances for details. -
AffordanceModelFactory.getAffordanceModel(…)
now receivesInputPayloadMetadata
andPayloadMetadata
instances instead ofResolvableType
s to allow non-type-based implementations. Custom media type implementations have to be adapted to that accordingly. -
HAL Forms now does not render property attributes if their value adheres to what’s defined as default in the spec. I.e. if previously
required
was explicitly set tofalse
, we now just omit the entry forrequired
. We also now only force them to be non-required for templates that usePATCH
as the HTTP method.