Before we discuss it any further, let's see a popular example of the usage of HATEAOS, which is to buy a cup of coffee via a RESTful API, like the following:

POST https://api.examplebucks.org/orders HTTP/1.1
Content-Type: application/json
Content-Length: 33

{"drink": "latte", "quantity": 1}

This is a POST request, which has been sent to order a cup of latte. In its response, the server provides information about what the client can do next, as shown in the following code:

{
  "id": 12345,
  "drink": "latte",
  "quantity": 1,
  "cost": "5",
  "status": "pending",
  "_links": {
    "self": {
      "href": "https://api.examplebucks.org/orders/12345",
      "type": "GET"
    },
    "payment": {
      "href": "https://api.examplebucks.org/payments/12345",
      "type": "PUT"
    },
    "update": {
      "href": "https://api.examplebucks.org/orders/12345",
      "type": "PUT"
    },
    "cancel": {
      "href": "https://api.examplebucks.org/orders/12345",
      "type": "DELETE"
    }
  }
}

As you can see, in the response, the _links property, which is a hypertext that follows the HAL convention, contains operations that the client can take. In this _links object, each key standard for a relationship, and the href property of that relation is the URI of the resource, while the type property is the HTTP method that should be performed on that resource. In this example, the server provides operations, including making a payment, updating the order, and canceling the order. The self relationship is required for referencing the order resource itself.

The following is according to Roy T. Fielding:

So, if a client needs to update an order, it can go through the _links hypertext and find the update operation. And when the client needs to cancel the order, it can find the cancel operation in the hypertext and send a DELETE request to the URI specified in that operation.

Also, with the _links hypertext, API developers can change the URI of a resource without breaking the clients, since the hypertext decouple the clients from the URIs of resources. Clients do not need to hardcode URIs anymore. All they need to understand is the meaning of each operation that was returned in the _links hypertext. This is important when you do not have control of the clients of your APIs. For example, when you are building APIs that are publicly available, such as Twitter's, you won't have the control of most of the clients—and you certainly do not want to break them when you want to fix a typo in a resource URI. According to the HATEOAS advocates, another benefit is that your API becomes more self-descriptive and the clients don't have to look up the documentation that often. They can simply check the hypertext in the API response in order to navigate through your RESTful APIs, making the APIs discoverable.

That's the basic idea of HATEOAS. As mentioned previously, Roy T. Fielding insists that REST APIs must be hypertext-driven.