The same problem exists in HTML pages, which are also REST services. In HTML, the implicit assumption is that a living being is reading the page. In that context, there’s usually an excellent evolving REST conversation.

The reason I’m bringing HTML into the picture is because HATEOAS wasn’t coined in the context of “RESTful web services.” It was coined in the context of REST as Roy Fielding understood it in 2000. Roy Fielding’s context was HTML/HTTP/URI that have people as clients. In that context you have a rich set of additional information about a URL that the “client” can understand: readable text, images and other cues.

The question still remains as to how to “engineer for [conversation] serendipity” in the context of performing tasks using machine-to-machine conversations with REST APIs. How can you add more cues that a machine can understand? I personally find “rel” to be useful, but not expressive enough to define what the link IS; “rel” only describes a relationships between the link and its “parent”. HTML already has better solutions for the needs of programmatic processing: DOM manipulation based on semantic markup of id and class.

Web sites also employ “Information Architects” whose reponsibility includes assuring that Web sites as a whole meet the needs of every type of system user. Information Architects assure that each type of task has an appropriate path/conversation through the system. REST data services should probably be approached the same way. When publishing an API, one needs to consider the overall notion of guided paths through the functionality.

I think that we’re at a point where we need a bigger focus on the conversational aspects of REST services. To get there, we probably need better tooling and better “best practices.”

But this is all very much work in progress right now.

Content-Type: application/mymediatype+mylinkrelations+xml

I’m not against the general idea, but I’m not sure what it would look like in practice.

re 2) Forms are probably great if you’re using an XML-based media type. Lately, I’ve been using JSON, not XML, and AFAIK there is no equivalent to forms for JSON. As I needed parameterized queries, I resorted to (a simplified variant of JSON Query). Thus, I’m guilty of pasting together URLs, but I reckon it’s only half bad because I use a generic formalism.