Comment by comex | Hacker News Reader

Comment by comex | Hacker News Reader

Making a client add a level of indirection through <link> elements to figure out what URL to use is not inherently a good thing: it's easy for clients to get wrong, requires the use of XML rather than other output formats (sort of), and generally adds complexity without an obvious benefit. The example given was that the URL might change, and clients would be able to follow along like humans; but unlike humans, which can autonomously start using new functionality and new site organization, computers are very unlikely to be able to automatically provide a useful submission to a new API - and if the API doesn't change (or is backward compatible), there is no good reason to change the URL unless the URL is excessively coupled to the implementation. The only other benefit I can think of is that humans testing the API might use the list of available API calls, which is actually pretty reasonable, but the article seems to be articulating this as something more fundamental than a debugging aid.

In other words, how is this a good thing?

You definitely aren't tied to XML, it is just one possible format for delivering hypermedia. I'm nothing close to an expert, but enjoy the concept. Github is doing cool things with hypermedia in their API.

> there is no good reason to change the URL unless the URL is excessively coupled to the implementation.

Here's one: It provides an easy means of making a system more resilient and scalable, by allowing the implementation to tell you "now go talk to this cluster over here" instead of using e.g. anycast (which is complicated) or still being dependent on your main load balancers.

Now, you can do that "wholesale" for the whole application. E.g. Yahoo Mail will redirect you to a specific mail cluster on login. But indirection on the resource level gives you more flexibility.

The URL might in other words be user specific, or even dependent on other factors such as which access rights the user have, or what service level they've paid for.

You can of course do that by encoding it in your client app. But then you will need to duplicate it, since you'll need to authorize the access on the server side for enforcement too, instead of encoding the information in some sort of policy on the server side that can both be used to generate the right links, and authorize access from a single source (of course you can do this to generate a custom client for each user login too, at the cost of blowing all your caching and CDN benefits out of the water).

The API (which, in a RESTful world, is just the media types) doesn't have to change, but the provider can. If you used standard media types, you could e.g. replace the comments in some application with say, Disqus without having to touch a client (that you often don't even control).

HATEOAS seems useless because we're still building primitive APIs and reinvent media types (read: custom, non-documented JSON documents) for no good reason, while we recreate the same functionality over and over again while improving only at the edges.

Frankly, I think it's a damn miracle that smart people convinced us of the benefits of the web, because we regular developers seem unable to see anything five centimeters past our noses.

By the way, to show that you don't have to use XML, here's my favorite URI-supporting encoding type, Turtle: https://en.wikipedia.org/wiki/Turtle_(syntax)#Example

Reply on news.ycombinator.com