I'm interested in using the HATEOAS principle of REST to reduce business logic in a SPA application. In a React-specific context, I'd like to know if there are challenges that make this impractical and, if not, what is a good strategy to follow?
Conceptual examples of using HATEOAS to remove business logic from the UI:
I've only found one link that suggests React/Flux is not compatible with a HATEOAS strategy, and no meaningful discussion elsewhere. Is it really not feasible in a React/Flux app? That SO post didn't get enough attention. Does anyone have a favorite or recommended approach for achieving success (with or without Flux or Redux)?
Someone gave a fairly detailed example of leveraging HATEOAS in the context of Angular. I'm looking for something similar for React.
Personally, I'm picturing the rel
tag in hypermedia links controlling which JSX components are rendered (conditional JSX). Is that naive for a real-world React app? Perhaps conditionally rendered React components are too coarse-grained to be used this way?
I am assuming that hypermedia links are provided by a HAL implementation, or otherwise conform to the ATOM feed convention (RFC4287).
Developers describe Django REST framework as "Web APIs for Django". Django REST framework is a powerful and flexible toolkit that makes it easy to build Web APIs. On the other hand, React Native is detailed as "A framework for building native apps with React".
With HATEOAS, a client interacts with a network application whose application servers provide information dynamically through hypermedia. A REST client needs little to no prior knowledge about how to interact with an application or server beyond a generic understanding of hypermedia.
It never has been, it's a much higher level than that. But when you do need REST, and you do use REST, then HATEOAS is a necessity. It's part of the package and a key to what makes it work at all.
100% HATEOAS IS compatible with React & Flux, HATEOAS is compatible with Angular, HATEOAS is compatible with JQuery and even vanilla JS.
HATEOAS doesn't not impose any technical or implementation requirements on a consuming client.
HATEOAS is in fact simply a concept to which you can design your API (you can use one of several standards though like HAL)
Basically if you can call an API then you can implement a HATEOAS client.
So how to get there:
For example given a call to the order api /orders
, I get the following response:
{
"_links": {
"self": { "href": "/orders" },
"next": { "href": "/orders?page=2" }
}
}
From this I can infer that next
is a valid relation, and that if I go to that href I would in fact receive a second page of orders, so in this case in the UI show the next button.
However if I had received the following response:
{
"_links": {
"self": { "href": "/orders" },
}
}
Then I could infer that next
is not a valid relation, and in my UI I should disabled or not display a next button.
There is no magic, it is simply a change in thinking, a new paradigm.
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