4 ms·

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

by mythz 14y ago

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.

dllthomas 14y ago
If your software understands the hyperlinks, isn't it more accessible to mashups and such?
vidarh 14y ago
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.
parasubvert 14y ago
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.

by mythz 14y ago

dllthomas 14y ago

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

vidarh 14y ago

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.

parasubvert 14y ago

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.