Prototype fortune router

[craigedmunds]

We envisage the creation of a component that sits in front of multiple instances of fortune, either running in the same process, or remotely, and allows us to use JSON-API semantics and provide other aggregation across service boundaries. This allows a client of this API to interface with a single API and the fact that it’s actually implemented in multiple services to be completely opaque. The services can also be local, in the same service, or remote, again, completely transparent to the consuming client.

This routing component is documented in more detail here.

A simple example of how this could look can be seen here, showing one fortune instance with user and address resources, and another with a flight resource.

The routing component needs to facilitate:

• cross-service resources as single solid document (GET /resources should return metadata describing both fortune instances)
• cross-service linking (GET /users?include=flights should work)
• cross-service compound documents (POSTing a user with associated flights should work)
• cross-service filtering (GET /flights?filter[user.firstName]=Craig
• cross-service metadata via /resources