[simiones]

> In HATEOAS, the client doesn't care at all about whether the page contains a "status". It displays the hypermedia the way it is given without knowing the semantics at all - that's what makes it de-coupled from the server. It only knows the semantics of the hypermedia, in this case HTML.

This is not exactly what the REST thesis advocates for. You can absolutely create a true REST client for something much more specialized and narrow purpose than HTML. The main point of REST is that your client and server should both understand the media type, and then be developed independently to have all the semantics of that media type.

HTML is not a special media type in this sense. It just happens that it's an extremely broad format, broad enough to encompass almost the entirety of the web. But not all REST APIs need to be this broad: you can create specialized REST APIs for specialized media types.

In principle, the definition of a true REST API would be: can you create a a fully conforming client for the REST API by just reading and implementing the definition of the media type + using the HTTP verbs? If yes, then the API is truly REST like. If you need any other out-of-band information, then it's not. Note that knowing URLs is already out of band information.

[brabel]

Completely agree... it's just that it's very rare to see truly hypermedia-driven APIs out there, other than the Web itself.

I've seen only one, and that's one I helped develop.