I have been looking into REST, specifically HATEOAS on Wikipedia, and it is stated that
The principle is that a client interacts with a network application entirely through hypermedia provided dynamically by application servers
How else is a client going to interact with with an app, if not through hypermedia?
What are some code examples of non-HATEOAS interactions?
Non-HATEOAS APIs require prior knowledge about the resources and relationships between them.
For example, if thinking about a library API, a 'book' resource may have a name or ID of its author as an attribute. To get more information about the author the API client has to somehow know that the 'author' resource has specific context path and that it's ID is the attribute value. The things get even more complex if client would want to borrow that specific book. To do that it has to know that a POST request has to be done to create some specific resource with certain attributes (like the book's ID). The knowledge of how to do such things has to be hardcoded in the client implementation. In HATEOAS each 'book' would have links to all related resources and it would also contain information about actions that are related to that book.
The PayPal Customer Disputes API could serve as a real world example non-HATEOAS API. Check the 'list disputes' part: it provides a list of resources with various attributes. Then see the 'provide evidence' part. It says that the client may provide a resource related to a dispute. It is not possible to figure it out just by following links in the resources in the API. If it was HATEOAS then there should be a link of some sort in the 'dispute' resource that would convey the possibility of adding an 'evidence' to each dispute. You, as a programmer, have to read the documentation in order to know that 'disputes' can have 'evidences' added.
I really recommend this video as an excellent learning material about what HATEOAS is and how relationships between resources can be expressed.