One of the requirements that should be satisfied before you can call an API 'RESTful' is that it should be possible to write a generic client application, on top of that API. With the generic client, a user should be able to access all the API's functionality. A generic client is a client application that does not assume that any resource has a specific structure beyond the structure that is defined by the media type.
In your example, the client application would offer the user the ability to follow the links. The
rel attributes are displayed to the user and the client application expects the user to understand these values.
The above is known as the REST requirement to have "Hypermedia as the engine of application state" (HATEOAS). The benefit is, that the client won't break when the back end changes its
rel values. Without HATEOAS, the interface is not RESTful.
Is this the end of HATEOAS and thus the end of REST? Yes and no.
Yes, because if we hard-code knowledge about the API into the client, we lose the benefit of HATEOAS: server-side changes may break the client.
No, for two reasons:
- Being "RESTful" is a property of the API, not of the client. As long as it is possible, in theory, to build a generic client that offers all capabilities of the API, the API can be called RESTful. The fact that clients don't obey the rules is not the API's fault. The fact that a generic client would have a lousy user experience is not an issue. Why is it important to know that it is possible to have a generic client, if we don't actually have that generic client? This brings me to the second reason:
- A RESTful API offers clients the option to choose how generic they want to be, i.e. how resilient to server-side changes they want to be. Clients which need to provide a great user experience may still be resilient to URI changes, to changes in default values and more. Clients doing batch jobs without user interaction may be resilient to other kinds of changes.
If you are interested in practical examples, check out my JAREST paper. The last section is about HATEOAS. You will see that with JAREST, even highly interactive and visually attractive clients can be quite resilient to server-side changes, though not 100%.