Description
While experimenting with the Hal support it occured to me, that maybe we should re-focus the current approach to providing both our own and third-party hypermedia content types. The current Resource classes with their json links and content attributes are in fact yet another way of adding hypermedia controls to json, IOW we are establishing yet another hypermedia content-type, without defining a proper content-type for it (at least not yet).
Maybe we should use Resource and Resources as an abstraction which is meant to be represented in more widely-used hypermedia formats (atom, hal, siren, collection+json, json-ld, xhtml) - as requested by the client via Accept. I think this is what has just started by adding Hal. Enabling people to build abstract hypermedia resources and making the representation a matter of choice or taste would be the correct thing to do IMO. We could provide MessageConverters for the media types.
To support these media types better, Link seems to need these extensions:
- templated URIs (e.g. used by HAL), in the formatting used by http://tools.ietf.org/html/rfc6570. At least we must be able to render templated='true' if the href contains variables, as in this hal fragment:
"find": { "href": "/orders{?id}", "templated": true } - additional link attributes as defined in http://tools.ietf.org/html/rfc5988
- a link can have multiple rels attached to it, as in the example from RFC 5988 - maybe we should reflect this and make the rel attribute a List
Link: http://example.org/;
rel="start http://example.net/relation/other"
Resource and Resources could be extended by the following properties:
- actions (used by xhtml forms, Siren)
- context (e.g. used by json-ld)
or maybe simply a facility to add arbitrary Object properties to it, so that people can add data to the Resource as needed.
I want to find out in which direction you are going here. We can then create single User stories and add these extensions one at a time.
Best regards
Dietrich