Currently, address can only do requests to the local web. Whenever you do something like the following, it'll only work if the path has a registered resource:

address('/my/data').json().get()

I propose we amend address with the ability to make this request across the boundaries of the local vm, such that remote webs (i.e. the "real" web) can be fetched just as well. This would allow users of address to utilize it as a one-stop shop for anything related to a web request, including things such as linking (see #28,) regardless of whether or not the request makes it across the internet or stays in local memory. It'd also be a stepping stone to having universal applications, where the first request crosses boundaries, but subsequent requests hit a local resource fetched transparently by address, because the server across the web told address there was a resource representation to that effect. (I'll write this up in a different issue and link back.)

So how would this look from an API standpoint? Like this:

address('/my/data').json().get()

That is, there is no discernible API difference, and the switch would happen internally in address. The process would be something like this, when a user dispatches a request:

1. Peer into the local web; is there a handler registered at /my/data?
   • yes: dispatch handler; goto 3
   • no: serialize request and dispatch via appropriate mechanism (fetch where available; XHR elsewhere)
     • deserialize response as it arrives
2. Process request and call response handlers as normal; users are none the wiser as to what just happened

We can (and should) let the user know via response headers what actually went down, because it helps in debugging. The Server field is a good candidate (e.g. it could be nap or something whenever it's in-memory and whatever else at other times.)

Background

This idea was floated during a call with @gabrielmontagne, wherein he described an issue with the client making three identical requests at the same time, meaning the requests haven't yet been cached (since there haven't been a response) and so performance penalties occur. The discussion focused on finding a way to piggy-back on the first request, such that the subsequent requests would get the exact same response. This implies shared state, but we don't want this to be known by the code making the request, we want to keep the naiveté of just making requests willy nilly, yet be smart about it.

So the idea is to say: so long as you use one client, i.e. address, you'l get these fringe benefits of piggy-backing on identical requests, and potentially others (such as the linking/universal handler mentioned above.)