What is the HATEOS compliant way of accepting parameters? E.g. for the pagination example, you might want to let the consumer specify number of entries pr. page, or you might want to accept a search-term or limit by period.
So
href="foo/bar/?baz=x"
For instance, if there are 10 pages then x ranges over [1-10]. If the client request ?page = 11 then we'd return a 405 error indicating that the only valid values are [1-10].
In your example, I need to know that the x is something that requires replacement. How is that fundamentally different from just putting in your documentation (and, in the 405 if not passed) "this resources takes query param baz" - which is not HATEOS?
Also, this doesn't cover the case of optional parameters. Specifying optionality in a template is horrible (something like "bar/?baz=x[&ogle=y]" to borrow the pattern from man pages), and specifying individual URLs for each combination of parameters is impractical for more than a few.
This is why a standard has been drafted for this particular problem, the mangling becomes standard and predictable rather than customized to each use case.
Web browsers are REST clients that understand the HTML resource type. They, too, can generate URLs. For example, in HTML, you can specify a URL template with the following code:
<form action="foo/bar/" method="get">
<input name="baz" type="text">
<input type="submit" value="Submit" />
</form>
You can define your custom resource type to do the same if you want:
{ "form": { "action": "foo/bar/",
"method": "GET",
"fields": [ { "name" : "baz" } ]
}
However, getting a client to automatically understand this is a little harder.
You could approximate a form in JSON, which would be similar in structure to its HTML counterpart.
it would accept parameters. I think having a template requires the client to understand a format other than hypertext.