Make Resource and Resources a general abstraction for hypermedia resources

[dschulten]

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

[fiddlerpianist]

I would love to see this type of change made as well. I'm having difficulty making the Resource(s) work in a particularly HAL-friendly kind of way. Currently it appears that the code simply maps Atom names to HAL names on serialization rather than supporting a more full-featured content model for links and resources.

[mortizbey]

+1

[drewcox]

+1, I am also trying to render templated HAL links and there appears to be no way to do it. I'd be happy to even find a way to extend the project with some custom coding?

[gregturn]

Resolved via #833.