Hacker News Reader

> Where this kind of API design is useful is when there is a user with an agent (e.g. a browser or similar) who can navigate the API and interact with the different responses based on their media types and what the links are called.

The funny thing is, that perfectly describes HTML. Here’s a document with links to other documents, which the user can navigate based on what the links are called. Because if it’s designed for users, it’s called a User Interface. If it’s designed for application programming, it’s called an Application Programming Interface. This is why HATEOAS is kinda silly to me. It pretends APIs should be used by Users directly. But we already have that, it’s called a UI.

The point is that your Web UI can easily be made to be a REST HATEOAS conforming API at the same time. No separate codepaths, no duplicate efforts, just maybe some JSON templates in addition to HTML templates.

You're right, pure REST is very academic. I've worked with open/big data, and there's always a struggle to get realistic performance and app architecture design; for anything non-obvious, I'd say there are shades of REST rather than a simple boolean yes/no. Even academics have to produce a working solution or "application", i.e. that which can be actually applied, at some point.

When there is lots of data and performance is important, HTTP is the wrong protocol. JSON/XML/HTML is the wrong data format.

> Where this kind of API design is useful is when there is a user with an agent (e.g. a browser or similar) who can navigate the API and interact with the different responses based on their media types and what the links are called.

It's also useful when you're programming a client that is not a web page!

You GET a thing, you dereference fields/paths in the returned representation, you construct a new URI, you perform an operation on it, and so on.

Consider a directory / database application. You can define a RESTful, HATEOAS API for it, write a single-page web application for it -or a non-SPA if you prefer-, and also write libraries and command-line interfaces to the same thing, all using roughly similar code that does what I described above. That's pretty neat. In the case of a non-SPA you can use pure HTML and not think that you're "dereferencing fields of the returned representation", but the user and the user-agent are still doing just that.

> Government portals for publicly accessible information, like legal codes, weather reports, or property records

Yes, and it's so nice when done well.

https://www.weather.gov/documentation/services-web-api

> Where this kind of API design is useful is when there is a user with an agent (e.g. a browser or similar) who can navigate the API and interact with the different responses based on their media types and what the links are called.

> Most web APIs are not designed with this use-case in mind.

I wonder if this will change as APIs might support AI consumption?

Discoverability is very important to an AI, much more so than to a web app developer.

MCP shows us how powerful tool discoverability can be. HATEOS could bring similar benefits to bare API consumption.