Spring HATEOAS versus Spring Data Rest
HATEOAS stand for Hypermedia as the Engine of Application State and is one of the key ponit of REST. Basically the key point consist to use links on the your resource representation for map the valid transition of the application state. In this case will be the service provider that provide the valid next correct state of the your application reachable through the link. Spring HATEOAS is the Spring projects for help to build the Hymeridia Controls in your Resource. It is a project integrate with Spring MVC and you can think as the Spring MVC extension for building a real RESTFull WS whit a very good support for increase the level of the your service form CRUD (level 2 of maturity in the Richardson model) to an Hypermedia aware (level 3 of maturity in the Richardson model). Spring Data Rest on the other hands is a very nice project that use Spring HATEOAS as basic brick, for give you a repository layer usable as restfull ws. In proctis the project help to reduce the classical boliporlent code for expose the your repository layer as a restfull endpoint. We can say tat was the propouse of the projects very different. With Spring HATEOAS you had a framework usable for any kind of restfull endpoint, with spring data rest you had a spring project that already provide an endpoint and a framework for customize it.
I hope that this reflections can help you to clarify the difference between the two projects and understand better how use one or the other
Spring HATEOAS provides common abstractions (representational models, a Link
class, API to build links pointing to Spring MVC controllers, etc.) to ease building hypermedia driven REST APIs with Spring MVC in general. Thus, you can use it alongside Spring MVC to manually build those services.
Spring Data REST uses Spring HATEOAS to automatically expose resources for entities managed by Spring Data repositories and leverages hypermedia aspects to do pagination, link entities etc. So it covers the 80% use case for the basic stuff and allows you to selectively add more complex processes using manually implemented controllers later on.
To get a feel for this, feel free to have a look at the Spring RESTBucks sample project. The handling of Order
instances is completely done by Spring Data REST (with some minor tweaks to implement business constraints). The entire payment logic is then implemented manually as the process does not fall into the CRUD category as we actually need to implement certain steps and a protocol to complete the order. Again, the code is here, a slide deck with some additional visuals can be found at speakerdeck.com.
I chose to use both of them in my project. One layer of controllers was built with Spring Data REST. The other layer of controllers was @RestController's (spring-wevmvc). In this layer I used Spring HATEOAS to create customed page's.
(Process was :
1.creating Pageable Pageable pageable = new PageRequest
2. creating new Page Page<FooDt> page = new PageImpl<FooDt>
3.creating PagedResources PagedResources<Resource<FooDt>> resource = fooAssembler.toResource(page, fooAssembler)
after that process using Jackson's ObjectMapper to return json.
The solution that I found for loading to context both technologies - is using two DispatcherServlet's. Otherwise, Spring Data Rest is taking control and there is no option to use other controllers. ( In that way I had two domains in my app. One for Data Rest and one for webmvc+HATEOS).