Most of the APIs I use and build are best suited as RPC systems rather than hypermedia networks, so implementing the entire REST idea has never been immediately useful. Broadly the real consumers of RESTful APIs are not generic hypermedia clients (generalisation of browsers) which are able to traverse your flavour of hypermedia, but the things operating those clients. Most of the time, those “things” are dumb business logic applications that can’t explore the hypermedia to discover
new functionality and furthermore are not designed to do anything with it anyway.<p>If it is a human traversing the hypermedia however, they’re able to derive a lot of understanding about the API and its features, as if the API is self documenting, but that generally only occurs
during the development and debugging stages. After that the hypermedia is useless to the dumb business logic. Also I’m sure most humans prefer to browse the documentation on the alternative World Wide Web hypermedia network, as any good API would have documentation published there.<p>All in all hypermedia is mostly useful for intelligent consumers, so if that is not the consumer of your API and you suspect instead the consumer will be static business logic (the vast
majority of cases) then REST will not be particularly useful. As I mentioned an interesting use case would be bundling up documentation into the API itself and hyperlinking between that and related URLs, however the overhead is generally not worth it since you’re likely to do it better with documentation site.