Comment by Milagre | Hacker News Reader

Comment by Milagre | Hacker News Reader

Parent Full thread

OP here.

I'm not strictly advocating HATEOS. Hypermedia and HATEOS are related but not the same concept. I am very strongly advocating hypermedia, as I believe it it greatly reduces the complexity of interacting with an API.

Never having to build a URL by hand is great! Being able to just grab a field from a resource, and go do a GET on its value is very easy to code, even if that process involves finding a link with a certain relation. You speak of complexity, and I'm speaking of convenience.

With that convenience also comes the ability to automatically crawl the data with good solid knowledge of how each resource relates to others, enabling the ability to create massive graphs of information. Like wikipedia has for humans to read, but structured and standard for computers to parse.

> His theoretical (well, implementations certainly exist) universal REST client only works when every API you want to consume standardizes to presenting the information in the same format.

That sounds like a great day to me.

> Never having to build a URL by hand is great! Being able to just grab a field from a resource, and go do a GET on its value is very easy to code, even if that process involves finding a link with a certain relation. You speak of complexity, and I'm speaking of convenience.

This kind of thing sounds great for exploratory development, but undesirable (for the reasons I outlined previously) for an actual production app.

> That sounds like a great day to me.

I hope you're used to waiting :).

> This kind of thing sounds great for exploratory development, but undesirable (for the reasons I outlined previously) for an actual production app.

For example production apps, see this comment, and the one it links to: http://news.ycombinator.com/item?id=4950877

(Ohhh, hypermedia. ;) )

> This kind of thing sounds great for exploratory development, but undesirable (for the reasons I outlined previously) for an actual production app.

We actually do this in our production app. The only URL we actually hardcode in the app is the root URL for the account currently logged into. (And a few other urls unrelated to the account, but that's honestly just pure laziness).

User logs in - we get the account (root resource)

Bootstrap the JS - we get a subresource of the account and request it, populating the initial UI

User interacts with UI - generates a GET to a URL we got from another resource, repopulates the UI with relevant data from that resource. Rince, repeat.

Doing this has made changing our API structure over the course of development a lot easier.

> I hope you're used to waiting :).

I am :). But I look at how much faster html5 went from concept to production because it was pushed by the browsers, and I experience an $optimism++. Things are moving in the right direction, IMO.

Reply on news.ycombinator.com