3 ms·

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

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.

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.
zachrose 14y ago
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.

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.

zachrose 14y ago

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.