HATEOAS with Ember Data

Ember Data introduced strong
conventions
around how to structure API responses. While these conventions allow us to move
quickly, there are additional steps we can take to minimize the coupling between
the front end and back end. Using concepts from
HATEOAS (Hypermedia as the Engine of
Application State) we can make our Ember applications more flexible and
resilient to changes on the server.

Ember Data can take advantage of API responses containing a links key pointing
to URLs to associated resources. Ember Data will automatically pick up on those
links as the source of the association’s data instead of using the default URL
structure. In a use case where we want to asynchronously fetch associated
resources, our API has more flexibility around URL structure.

Let’s say we have a Repo resource that has many Commits and we want the
commits to be loaded asynchronously in Ember. How would we set up our API
endpoints?

By default, Ember Data is going to fetch the commits with a call that looks like
/commits?ids[]=1&ids[]=4. For our use case, it makes more sense to have Ember
ask for all of a repo‘s commits without having to know the commit id’s
ahead of time. We’d like our endpoint to look like repos/1/commits. With this
structure the client is able to make requests such as, “Please give me all the
commits for this repo” instead of requests like “Please give me these specific
commits”.

We’re telling Ember Data to lazily fetch the commits from our specified
endpoint. As a result, if we later change our minds that we want the commits
resource to be available at a different URL, we can make that change without
touching the front end. The server is able to change its URL structure with no
impact on the front end.

The idea of returning links is not a new one. HATEOAS has been around for some
time and has a specific spec. It includes a more structured links object
including rel and href keys and a complete URL containing the host name.
Ember Data though asks you to follow the convention of naming the keys in
links to match the resource name. A strict HATEOAS implementation of the above
repo and commits example would look like:

If you enjoyed this post, you might also like:

Want to level up your testing game?
Learn about testing Rails applications and TDD
in our new book
Testing Rails.
The book covers each type of test in depth,
intermediate testing concepts,
and anti-patterns that trip up even intermediate developers.