if i am correct HATEOAS ist an architectural pattern and don't describe HOW a client should discover relations. HATEOAS just describe THAT a server should send a discoverable API to the client.
When adopting HATEOAS the api author can define HOW the client has to discover the relations.
For example without a standard like hydra / hal / jsonapi it's not clear if a json use "link", "_link", "links", "relations" fields in the json document to represent a relation.
From my point of view, this would allow me, as an api author to define something like this (valid HATEOAS):
The symbol "🔗" represents an array of hypermedia controls
Hypermedia controls are represented by a string.
The string can start with the reserved symbols "✔", "↯" and "±".
If the hypermedia string starts with "✔", the client is allowed to do a safe GET request to the URL. the URL follows the "✔" symbol and is rot13 decoded.
{
…
"🔗": [
“✔uggc://.../traerf/snagnfl”
]
}
From my point of view, this should be valid HATEOAS, or did i miss something?
Of course defining an own standard ontop of HATEOAS doesn't make sense.
There is no such standard or architectural pattern like "HATEOAS". There is REST(Representational State Transfer) Architectural Style(Style not pattern or something else) that comprises several constraints. One of the constraints is called as a - "Hypermedia as the Engine of Application State".
If the hypermedia string starts with "✔", the client is allowed to do a safe GET request to the URL. the URL follows the "✔" symbol and is rot13 decoded.
All of these are irrelevant(and pure design), only thing that matters is selected hypermedia type(HTML, Atom, Collection+JSON etc) and hypertext controls like:
that are defined by media type and not by conventions like "if the URL follows the symbol" etc...