Purpose of the Fork

The purpose of the forked hal-rfc is to hopefully add the temporal aspect into the HAL specification or understand why it is not necessary to add.

The aim to be able to inform clients/consumers of a given service using ´application/hal+json´ when was the last time this service checked the links in the ´_links´ section. This informs how old the individual link information is and the newest ´seen´ in a link collection would indicate the last time the links was checked as being still relevant.

Why is this interesting? The idea is that it actually allows the client/consumer to decide whether it wants to check the link or not, it is similar to the relation between _links and __embedded defined in the Hypertext Cache Pattern, which allows the client to get the linked resource directly if the client/consumer desires to do so.

This perception is derived from a conception of the object A having the __links and the __embedded part included are incorporating information that is not actually owned by the A object, but information that is related information, which means that it can have a life cycle different from the the A object. In a non HAL setup using HATEOAS it could imho. be discussed whether 203 Non-Authoritative Information should be used for that part, whereas HAL is a really nice and intuitive way to specify the Non-Authoritative parts of object A. Therefore it is difficult to se that temporal aspect handled in a header on the basis of the "age" of the response as a whole, something with a finer granularity is needed imho. Making the information available to clients/consumers about the potential "age" of the Non-Authoritative Information carried inside A by including that inside the A links as sketched below and in the suggested changes to the specification.

The inclusion of the _seen attribute seems to be a relative simple way to allow the client to decide itself, whether to check for the validity of links in the link collection or just show "what was the actual collection at time t", as it is right now the client/consumer does not know how old the link collection is and can therefore not be sure how old information is presented to e.g. a user.

We have included that attribute in the Jackson Data Mapper in order to enable the temporal aspects.

Please comment if you can improve the text and let us figure out if this is an appropriate way to solve this temporal aspect.