First class hypermedia support

[mstade]

Currently, we don't really have any good mechanisms or syntax for describing links. There are many kinds of links, with varying semantics, and while we don't have to support everything under the sun I believe there is a set of functionality that could bring us loads of value. For instance, the idea of resource level links, to allow for embedding resource data, or get away from using module loader plugins for things like CSS or text content.

Here's what such an API might look like:

export const link =
  [ { id: 'data', rel: 'embed', accept: 'application/json', href: '_self' }
  , { rel: 'style', href: 'main.css' }
  ]

export default function view(req, res, context) {
  res(ok(node => { node.innerHTML = context.data }))
}

Comparatively, this is what it'd look like currently:

import 'css/css!./main.css'

export default function view(req, res, context) {
  address(req.uri)
    .json()
    .get()
    .on('ok', function() {
      res(ok(node => { node.innerHTML = context.data }))
    })
}

It's more verbose but perhaps more importantly it doesn't really let us know the intent of the code that well from the outside. Also, note how if we wanted to embed multiple resources, the onus on how to best do this lies on the resource developer, which I think is wrong. With first class hypermedia primitives like this we make it a lot easier for developers to convey their intentions and reduces the risk for boilerplate-induced errors, like forgetting to deal with redirects or not handling errors properly.

[mstade]

Comment from @gabrielmontagne:

I think this is very important.
It'll help express things in a much cleaner way and will make resources so much smaller!

I was surprised to not find this in the resource declaration but on the module itself---though I can see that links are probably more related to specific implementations than to the resource as a whole.

Another thing that can then come from this is smarter client/server communications^[1]:
If you have three related resources "about to be rendered", and because of the links you know in advance what each of them will need, one could bucket or bundle a very precise server query that will fetch only the data needed for the next draw.

Each component will selfishly request what they want, but maybe a special data representation handler will get a single request with a list of the links it needs to get.. and when it responds, the individual request be fulfilled with only what they needed?

[1]: had a very long conversation with Beto about this.