I'm working on an Angular 4 front-end for an API built by another team. The API follows HATEOAS and provides me with hypermedia links with every single response.

I know the shape of the API and I figure I can just hard-code the URLs into Angular Services with minimal fuss. However, a colleague (who is a backend developer) is trying to convince me that I should take full advantage of the hypermedia because it will mean less coupling between the frontend and backend (and potential breakage if the API changes).

However, I'm stumped on how I'd even go about implementing a simple HATEOAS pattern using Angular's built-in Http service. How would I store/share the hypermedia/URL information in a way that doesn't couple all the services together and make them hard-to-test? There seems to be no examples out there.

Would trying to create a HATEOAS-friendly HTTP client even be a good idea, or is it likely not worth the trouble?

I'm working on an Angular 4 front-end for an API built by another team. The API follows HATEOAS and provides me with hypermedia links with every single response.

I know the shape of the API and I figure I can just hard-code the URLs into Angular Services with minimal fuss. However, a colleague (who is a backend developer) is trying to convince me that I should take full advantage of the hypermedia because it will mean less coupling between the frontend and backend (and potential breakage if the API changes).

However, I'm stumped on how I'd even go about implementing a simple HATEOAS pattern using Angular's built-in Http service. How would I store/share the hypermedia/URL information in a way that doesn't couple all the services together and make them hard-to-test? There seems to be no examples out there.

Would trying to create a HATEOAS-friendly HTTP client even be a good idea, or is it likely not worth the trouble?

• javascript
• angular
• rest
• hateoas

• 1 You find the url in the response by using a rel attribute and thrn store this url onto the entity itself. For example, when you receive a list of products, the link to each product details page is taken from the response and stored in your angular model. – Constantin Galbenu Commented Jul 26, 2017 at 21:16
• Thanks. Is it just me, or does that seem like a violation of the Single Responsibility Principle? Why should the the details/edit/update URLs on the API be embedded with a product's information? – Jon Gunter Commented Jul 26, 2017 at 22:35
• i don't think so. It's just meta information, highly cohesive with the product entity. If you hardcode/construct the url then you are creating an unnecessary dependency and add extra responsibility. – Constantin Galbenu Commented Jul 27, 2017 at 4:03
• See also here for some inspiration: github./mdvorak/resource-router Angular routing engine that drive views by media types. It loads data itself, and by response Content-Type header it displays configured view. It is a replacement for original Angular Router (they cannot be used at the same time). – Felix Commented Oct 12, 2019 at 8:18

1 Answer 1

Your colleague is right, you should use the meta information that the back-end provides. In this way you are not putting responsibility on the client that doesn't belong there. Why should the client know from where to fetch the entities? Storing the entities (in fact the data in general) is the responsibility of the back-end. The back-end owns the data, it decides where to put it, how to access it, when to change the location or the persistence type, anything related to storing the data.

How would I store/share the hypermedia/URL information in a way that doesn't couple all the services together and make them hard-to-test?

Why do you think using HATEOAS makes the testing harder? It does not, in fact not using it makes the testing harder as the URLs are static which makes the back-end non-stub-able.

You can extract the information from the back-end response and store it as meta-information in the angular model, on a _meta key or something like that.