Spring HATEOAS provides a generic link concept. In JSON:API, for relationships between rest resources, the relationsshipsattribute is in most cases the proper solution. Furthermore, JSON:API provides a links attribute, both for the top-level document, as well as for resource links. The only allowed member of resource-level links is self. So, if a Spring HATEOAS representation model contains only a self-link, the current serialization would be JSON:API compliant. An example is:
Furthermore, Spring HATEOAS allows adding several links with the same relation name. Currently this library serializes this as an array, which is NOT JSON:API complient. The JSON:API spec demats that a link with a unique name is always a JSON object, never an array.
I am currently thinking about solutions, that the always library creates JSON:API compliant results. Furthermore, I am thinking of validation capabilities and more specific link building support.
Spring HATEOAS provides a generic link concept. In JSON:API, for relationships between rest resources, the
relationsships
attribute is in most cases the proper solution. Furthermore, JSON:API provides a links attribute, both for the top-level document, as well as for resource links. The only allowed member of resource-level links isself
. So, if a Spring HATEOAS representation model contains only a self-link, the current serialization would be JSON:API compliant. An example is:But if you would add a link with the relation imdb, the current serialization would NOT be JSON:API compliant:
Furthermore, Spring HATEOAS allows adding several links with the same relation name. Currently this library serializes this as an array, which is NOT JSON:API complient. The JSON:API spec demats that a link with a unique name is always a JSON object, never an array.
I am currently thinking about solutions, that the always library creates JSON:API compliant results. Furthermore, I am thinking of validation capabilities and more specific link building support.