Comment by mythz | Hacker News Reader

Comment by mythz | Hacker News Reader

HATEOS is a solution aimed at solving the clients can't update problem. This was never really an issue since browsers (closest thing we have to a HATEOS client) always rolled out new upgrades, it's an even less of an issue now with todays auto-updating browsers.

It was also born in the web's early document-centric era where every action requires a full loop-back to the server and entire page reload, which is why it will never be used to create engaging and interactive apps.

The ideal use-case for HATEOS would've been to power native mobile apps since they can be difficult to update, but even then it's relatively non-existent with most mobile app developers realizing it provides worse end-user UX that takes more effort to achieve.

Basically 10+ years on and it's still only being used in academic circles where the few that are trying to implement it, are doing it to achieve full-REST compliance, and not anything to do with choosing the best tool for the job or trying to create the best end-user UX.

I've written an earlier post why HATEOS and Custom Media Types are often poor choices, generally requiring more effort and producing less valuable results: http://www.servicestack.net/mythz_blog/?p=665

FIFY:

"[Hyperlinks are] a solution aimed at solving the clients can't update problem. This was never really an issue since browsers (closest thing we have to a [Hyperlink-aware] client) always rolled out new upgrades, it's an even less of an issue now with todays auto-updating browsers. It was also born in the web's early document-centric era where every action requires a full loop-back to the server and entire page reload, which is why it will never be used to create engaging and interactive apps."

Which seems rather nonsensical. HATEOAS is just about about hyperlinks driving the application. Which is what the Web is, mostly, still, even though we have lots of crappy Flash restaurant sites.

There's two ways you might be correct: (a) REST API clients are complete silos and we no longer use hyperlinks to bridge across them or (b) JavaScript is more important than links.

(a) is sometimes true given the state of today's REST APIs, but not always - Google's APIs, Facebook's APIs, etc. all are fairly connected. Plus We still use Hyperlinks to bridge across "apps", of course, because of this proliferation of API silos still require URIs and even the browser as glue between them until more mature user agents evolve.

As for (B), REST always had Code-on-Demand (i.e. JavaScript) as an optional constraint alongside HATEOAS.

The point of HATEAOS is not about building individual apps, it's about building an ecosystem of integrated applications... i.e. the HTML web itself.

One area where I do agree with you: REST's constraints can and should be jettisoned if it makes sense for your use case. If you really want to make an app that's "engaging and interactive" and needs to be a silo by nature, then have at it.

And every time you click a hyperlink, you're requesting a full-loopback to the server and an entire page-reload. This limits it's ideal usages, e.g. it's better UX to use web sockets to live-update content, then get end-users to manually clicking hyperlinks. It's also not suitable for "mashups" (i.e. content/functionality from multiple sources) or stateful UI's (i.e. how most native desktop apps work).

And it's irrelevant in today's Single Page Apps, i.e. you're never going to be able to create a usable "Google Maps" or Google Docs-like applications that comply with HATEOS restrictions.

I'm not saying you can't build systems with it, just that it requires more effort to do and ultimately produces a worse UX - which is why it's an ignored technology/constraints.

If your software understands the hyperlinks, isn't it more accessible to mashups and such?

I don't understand your arguments at all. Here's a concrete way in which a single page app may make use of it, without affecting UX at all:

Instead of hardcoding a URI hierarchy to determine where to issue a request to in order to take various actions on a message in a collection, look for link tags to specify them.

The immediate benefit is that it allows the server to signal 1) what actions it supports in the current context. E.g. if you're logged in as a user with restricted credentials, it might not return a link for the "delete everything" action, and when the rules change only the server side (which already needs the knowledge of the rules to validate requests) will need to change 2) endpoints can trivially change and the client side application is automatically up to date.

How much harder is this? You need to output a few extra tags and attributes. On the client you need to replace some hardcoded strings with lookups based on an xpath expression. But at the same time there are many cases where you may be able to remove duplicated logic.

The most successful sites balance JavaScript-driven UX with HATEOAS.

It's funny you mention Google Maps - its great success has largely been due to its rich linkability and embedability.

That's the point of HATEOAS - your site is one island in an ocean sized app called THE WEB.

There's a reason Twitter abandoned hash bang URIs and even adopted a traditional full page refresh design for the first load of the site - it was faster and more flexible than routing everything through a JavaScript wall.

There is a reason that big monolithic Flash sites never felt right. They were fortresses of isolation in a sea of interconnection.

Now, I'll completely admit the "linked data web" is a much more infantile version than the HTML web, but it holds plenty of opportunity for great UX that is completely separate from the HTML page refresh model while expanding interconnectedness of data and actions.

Much as a web crawler crawls HTML, an HTTP crawler should be able to crawl an HTTP API. There are operational benefits here of being able to write monitoring and instrumentation tools that don't need to be updated and redeployed when your URLs change.

If this goes for a crawler, it's not so hard to see how it might be the same for an admin panel or CMS.

Sometimes when writing front-end JS apps, I'll develop a common abstract class for a family of resources, and the only unique information in each concrete subclass is it's URL structure!

Sometimes your data really is that boring, and you could develop an entire UI with different resource types without ever having to encode expectations in client-side code.

Web browsers aren't HATEOS clients, the web sites/applications they make accessible are.

I work with a team on a complex web service and agree with all of Steve K's points. A REST-like approach using appropriate HTTP verbs and a good resource design are (given the right use-case) a big win. The problem for me with HATEOS evangelists is that they seem to think it solves more problems than it actually does. Sure, we now have a layer of abstraction between logical and http link but for anything other than trivial changes you always have to have human readable documentation. HATEOS works brilliantly for the web because there is a human at other other end who understands what "new comment" is and how it's different from "new private message". My customers' API clients don't have this semantic understanding. Now I know that it helps dev's if they can navigate around my API but it's no substitute for well written documentation; HATEOS API's are something to strive for but not self-describing as some claim.

I agree that most clients don't have that sort of semantic understanding. that's because we are still at a stage where most of our APIs are just custom media types and a moderate improvement over yesteryear's WSDL. The improvement is the use of URIs and HTTP GET to mash data.

But the point of HATEOAS is that it doesn't have to be this way. The number of generic link relations are increasing, as are the numbers of useful generic media types. We are getting smarter, as an industry, with how to describe semantics in a machine readable way. It's a slow process because building generic designs is really hard. Today's HATEOAS advocates are trying to progress the state of the art, I can completely understand why a individual API author might ignore that constraint though.

Perhaps it's futile but I'm not certain our future 10+ years out is eternally building hard coded mashups.

> there is a human at other other end who understands what "new comment" is and how it's different from "new private message"

That's the great thing about media types and custom link relations, you can express the relationships and the formats in a way that a machine can understand, and add new functionality while needing less hardcoding. The thing this doesn't solve (in principle) is exposing new media types and relationships, that definitely requires updating on the client's end. But, it's a much better situation than "this url has a document with this format, I'll wget that url at the start of my program, parse this stuff out of it etc.."

Reply on news.ycombinator.com