HATEOAS Rel - Any Standards Yet?

I believe Hypertext Application Language (HAL) is a draft standard - attempting to standardise these links between hypermedia.

This is a link to the draft JSON specification https://datatracker.ietf.org/doc/html/draft-kelly-json-hal-03

The HAL specification enforces the "href" conforms with the "Target IRI" defined in Web Linking specification (RFC 5988)

There is an XML implementation of HAL using C# here https://github.com/tavis-software

The same GitHub repository above also contains an example .Net implementation of RFC 5988.

The Web Linking spec, RFC5988, as has been pointed out in another answer, defines some different types of link relationships. But it also instructs IANA to create a link relation registry and to allow further link relation registrations. That registry, which is the definitive list of public link relations, is available at iana.org/assignments/link-relations and will be updated as new relationships are registered.

Commonly used relations in HTTP APIs include:

• start (points from every resource back to the API start point)
• item (points from a collection to an item, e.g. from a Twitter user page to a tweet)
• collection (reverse of item)
• previous (these next four are for paginated resources, e.g. collections or multi-page articles)
• next
• first
• last
• create-form (points from a collection to a resource that describes how to create new collection items, e.g. a ‘New Item’ HTML or XForms form)
• edit-form (points from an item to a form for editing that item, e.g. an Edit Tweet button)

If your desired relation is not covered by anything on that list, your relation must be a URI. Further, it is advised to make that URI a dereferencable http URL at a domain under your control so that API clients can look up documentation for the relation, e.g. http://www.example.com/link-relations#tweets. Usually, your API start point will be a list of collections, each with a custom link relation that describes what type of resource each collection contains.

Before talking any further about HATEOAS standards, I want to emphasize that there are three main concepts in an API implementing HATEOAS (nowadays also known as Hypermedia API):

• The HTTP Protocol. You have to respect its constraints when using verbs and return codes. You should also know the role of headers, especially Content-type, and subtilities like idempotency of some verbs. See RFC 2616 for more
• The URI structuration. Which must only give info about targetting a resource, and avoid contextual data. Known bad examples are for example to include language /en/, version /v01/, format /json/ or even verbs /do-something/ in the URI. More about that in RFC 3986 and in REST guidelines
• Contextual data, which can be found in the body, request params, or in the headers

Developers of REST libraries have strong guidelines to follow regarding URIs and HTTP, but lack an universal standard about contextual data and how it mixes with application data in the JSON body of the requests.

This is why the standardisation effort around HATEOAS is mostly about making specifications about the media-type. There are several ones arond there

• JSON HAL (ca 2012), as outlined by Mark Jones is the most known
• Collections + JSON (ca 2013), which did not get much attention
• Verbose (ca 2014) tried to unify every other effort, but is only known by specialists
• Siren (ca 2017) has around 1k stars on github
• JSON:API (ca 2015 but still in progress) is the current reference, with a lot of implementations for its version 1.0, and the support of Steve Klabnik, who authored a lot of content around the subject

Regarding your original question, see HERE for the JSON:API statements about related resource links.

Hope this will help anybody having the same concerns in 2019.