Question is, what's the difference between Spring HATEOAS versus Spring Data Rest ?
I feel both can do the same, and Spring Data Rest (as part of Spring Data) seems a bit more alive.
https://github.com/spring-projects/spring-hateoas https://github.com/spring-projects/spring-data-rest
When would you 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 HATEOAS provides some APIs to ease creating REST representations that follow the HATEOAS principle when working with Spring and especially Spring MVC. The core problem it tries to address is link creation and representation assembly.
HATEOAS stands for Hypermedia as the Engine of Application State and it is a component of RESTful API architecture and design.
The Spring HATEOAS project is a library of APIs that we can use to easily create REST representations that follow the principle of HATEOAS (Hypertext as the Engine of Application State).
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With