Wip/api modules

Separate api into smaller separate modules, should make for easier testing.

Here's a rough outline of some of guidelines I used in implementing.

## `express.Router`

This implementation uses `express.Router` to establish a "clean"
routing namespace, with fresh middleware untainted by other modules or
other routes.

### each module is a "factory" function

Lots of good npm modules `module.exports` a function.  The function
often takes some options in order to configure a suite of functions
implemented by the module.   Mike Bostock in,
[towards reusable chart](http://bost.ocks.org/mike/chart/) explains
how to create functions the configure functions bound inside a
closure.

### async callbacks, `(err, result)`
A lot of node modules have a de-facto standard of using `(err,
result)` as the signature prototype for callbacks of all kinds of asyn
operations.

#### liberal use of `pipe`
The above callback system makes it possible to make interoperable
APIs, all of which are based on the concept of
[streams](http://streamjs.org/).
[Lots of modules](https://github.com/substack/stream-handbook)
implement the stream api protocol, including the `pipe` shortcut to
connect anything to just about anything.

Therefore, a lot of these modules use `event-stream` to quickly
implement and expose `pipe`able streams, often using a single
function.  Then `pipe` is used to connect the logic in between
modules.  Many module's streams can configure the logic that happens
inside the stream; the `configure` that creates the streams often take
options that can be used to influence the behavior.

### testable modules
Since each module is laid out to configure a suite of functions for a
very specific set of use cases, it's possible to create test suites to
appropriately configure and test each module.

Some tests are included, but more are needed.

## debugging/hacking

I try to design modules and functions such that while you are debugging or
developing, you can see all of the inputs and outputs in a single "page" or
pane on one screen.  An example of this is ensuring that while working
on a specific route or api function, it's often useful to be able to
reconfigure the middleware and parameters affecting that route without
switching to another source file or having to page through lots of
source.

Some care has been taken to ensure that functions' inputs and outputs
are visible or predictable by reading a single "page" of code at 80
columns. My terminal shows ~ `59` lines.  Many node modules seem to
have a magic kind of `100` line threshold, above which it's usefult to
consider designing a "configurable function" and exposing it from a
shorter module.

There are obviously exceptions, and often speed of development trumps
the guidelines I use, which are actually fairly flexible, and less
rigid in practice.