Get HATEOAS and Hypermedia right with Spring - Eugene Paraschiv @ Spring I/O 2016

Spring I/O 2016 - 19 -20 May Barcelona

In this talk I focus on a core aspect of REST - Hypermedia and HATEOAS and share the practical steps of building this out into an existing API with Spring HATEOAS and Spring Data REST.
You’ll first learn about the basics - content negotiation, API discoverability at the root and introducing links into the responses of your API to help guide your clients.
We’ll then go into more advanced scenarios such as versioning, evolving an API with the right use of Hypermedia and the JSON-API spec.

Finally, we’ll circle back and look at some great examples in public APIs in our ecosystem.

[kevinfleischer]

Good presentation. Wondering why not more people viewed it, yet.

[BJHzlz]

Good presentation. Its worthy to watch from head to toe

[arithmeticerror]

Its a complete waste of time & resources to use HATEOAS as a general principle, which is why very few people actually use this. My reasoning on why this is the case is mentioned below

It does not deliver on even the marketing part of it

The only supposed gain you get is that the client is protected from superfluous server side url changes, but not from semantic serverside changes

1. Your payload is bloated for every response with this `_links` section, bad for mobiles where latency & data has a price
2. Since you have to generate this extra luggage for every response, it wastes server resources (such as constructing this additional objects) for the rare chance that server might want to change its urls w.r.t client. If you use proper versioning scheme for your urls, it is explicit to the client that he need to use a newer version
3. If your API semantics change, client still to need to modify his code to accommodate this new changes, so not sure what we gain with all the pain of HATEOAS
4. Client developer needs look at documentation no matter what you do, as he need to know the meaning of each field in the response