Permit custom functionality to be injected into HTTP transport actions

[kadamwhite]

WPRequest currently does two things: It builds a string, then it allows HTTP requests to be submitted against the resource that URI string represents. The latter part of that behavior will benefit from being pluggable, as described in #211 and #213.

Exposing WPRequest itself is something I would like to avoid to keep the core workings of the library (its URI-builder behavior) safe from unexpected modification; but exposing the HTTP behavior and enabling it to be customized or extended not only solves the issue expressed in the linked issues around cache implementation, but also provides a better interface for specifying bespoke authentication behavior.

To that end, this commit moves WPRequest's HTTP logic into a separate http-transport.js module, and injects a copy of that module's exports into new WP objects. The default transports themselves are exposed in the (frozen) WP.transport property; they can be referenced from there to extend the transport logic to permit additional functionality to be injected into the request process, for example caching behavior (as suggested in #211). Example:

var site = new WP({
  endpoint: 'http://my-site.com/wp-json',
  transport: {
    get: function( wpquery, cb ) {
      var result = cache[ wpquery ];
      // If a cache hit is found, return it via the same callback/promise
      // signature as the default transport method
      if ( result ) {
        if ( cb && typeof cb === 'function' ) {
          cb( null, result );
        }
        return Promise.resolve( result );
      }

      // Delegate to default transport if no cached data was found
      return WP.transport.get( wpquery, cb ).then(function( result ) {
        cache[ wpquery ] = result;
        return result;
      });
    }
  }
});

@edygar please review and see whether this API makes sense; this provisionally closes #211. (Note however that this PR does not yet address #213 in any substantive way.)

[kadamwhite]

@edygar I'd love to know if you have any feedback on this patch, whenever you have a moment! If it looks like it will resolve #211 I'll merge it in and get it in the next release later this week.

[edygar]

@kadamwhite I've been playing this all day! I'm sorry to let you waiting for so long for a feedbacks. So far so good! It allowed me to hook in the way I would like to. #211 is resolved with this patch.

[kadamwhite]

@edygar Awesome, I'm glad to hear it! Expect this interface to be released by Friday.

[kadamwhite]

Released today in v0.10!