batch_api 0.1.1 → 0.2.0

data/lib/batch_api/processor/executor.rb

@@ -0,0 +1,18 @@
+module BatchApi
+  class Processor
+    # Public: a simple middleware that lives at the end of the internal chain
+    # and simply executes each batch operation.
+    class Executor
+
+      # Public: initialize the middleware.
+      def initialize(app)
+        @app = app
+      end
+
+      # Public: execute the batch operation.
+      def call(env)
+        env[:op].execute
+      end
+    end
+  end
+end

data/lib/batch_api/processor/sequential.rb

@@ -0,0 +1,29 @@
+module BatchApi
+  class Processor
+    class Sequential
+      # Public: initialize with the app.
+      def initialize(app)
+        @app = app
+      end
+
+      # Public: execute all operations sequentially.
+      #
+      # ops - a set of BatchApi::Operations
+      # options - a set of options
+      #
+      # Returns an array of BatchApi::Response objects.
+      def call(env)
+        env[:ops].collect do |op|
+          # set the current op
+          env[:op] = op
+
+          # execute the individual request inside the operation-specific
+          # middeware, then clear out the current op afterward
+          middleware = InternalMiddleware.operation_stack
+          middleware.call(env).tap {|r| env.delete(:op) }
+        end
+      end
+    end
+  end
+end
+

data/lib/batch_api/{middleware.rb → rack_middleware.rb}

@@ -1,5 +1,5 @@
 module BatchApi
-  class Middleware
+  class RackMiddleware
     def initialize(app, &block)
       @app = app
       yield BatchApi.config if block
@@ -12,7 +12,7 @@ module BatchApi
           result = BatchApi::Processor.new(request, @app).execute!
           [200, self.class.content_type, [MultiJson.dump(result)]]
         rescue => err
-          BatchApi::Errors::Request.new(err).render
+          ErrorWrapper.new(err).render
         end
       else
         @app.call(env)

data/lib/batch_api/response.rb

@@ -1,5 +1,3 @@
-require 'batch_api/error'
-
 module BatchApi
   # Public: a response from an internal operation in the Batch API.
   # It contains all the details that are needed to describe the call's
@@ -15,6 +13,15 @@ module BatchApi
       @body = process_body(response[2])
     end
 
+    # Public: convert the response to JSON.  nil values are ignored.
+    def as_json(options = {})
+      {}.tap do |result|
+        result[:body] = @body unless @body.nil?
+        result[:headers] = @headers unless @headers.nil?
+        result[:status] = @status unless @status.nil?
+      end
+    end
+
     private
 
     def process_body(body_pieces)
@@ -24,12 +31,7 @@ module BatchApi
       # so turn it into a string
       base_body = ""
       body_pieces.each {|str| base_body << str}
-      should_decode? ? MultiJson.load(base_body) : base_body
-    end
-
-    def should_decode?
-      @headers["Content-Type"] =~ /^application\/json/ &&
-        BatchApi.config.decode_json_responses
+      base_body
     end
   end
 end

data/lib/batch_api/version.rb

@@ -1,3 +1,3 @@
 module BatchApi
-  VERSION = "0.1.1"
+  VERSION = "0.2.0"
 end

data/readme.md

@@ -1,7 +1,52 @@
-A proposal for a Batch API endpoint.
+[![Build Status](https://secure.travis-ci.org/arsduo/batch_api.png?branch=master)](http://travis-ci.org/arsduo/batch_api)
 
-Batch requests take the form of a series of REST API requests,
-each containing the following arguments:
+## What's this?
+
+A gem that provides a RESTful Batch API for Rails and other Rack applications.
+In this system, batch requests are simply collections of regular REST calls,
+whose results are returned as an equivalent collection of regular REST results.
+
+This is heavily inspired by [Facebook's Batch API](http://developers.facebook.com/docs/reference/api/batch/).
+
+## A Quick Example
+
+Making a batch request:
+
+```
+# POST /batch
+# Content-Type: application/json
+
+{
+  ops: [
+    {method: "get",    url: "/patrons"},
+    {method: "post",   url: "/orders/new",  params: {dish_id: 123}},
+    {method: "get",    url: "/oh/no/error", headers: {break: "fast"}},
+    {method: "delete", url: "/patrons/456"}
+  ],
+  sequential: true
+}
+```
+
+Reading the response:
+
+```
+{
+  results: [
+    {status: 200, body: [{id: 1, name: "Jim-Bob"}, ...], headers: {}},
+    {status: 201, body: {id: 4, dish_name: "Spicy Crab Legs"}, headers: {}},
+    {status: 500, body: {error: {oh: "noes!"}}, headers: {Problem: "woops"}},
+    {status: 200, body: null, headers: {}}}
+  ]
+}
+```
+
+### How It Works
+
+#### Requests
+
+As you can see from the example above, each request in the batch (an
+"operation", in batch parlance) describes the same features any HTTP request
+would include:
 
 * _url_ - the API endpoint to hit, formatted exactly as you would for a regular
 REST API request (e.g. leading /, etc.)
@@ -9,137 +54,165 @@ REST API request (e.g. leading /, etc.)
 * _args_ - a hash of arguments to the API. This can be used for both GET and
 PUT/POST/PATCH requests.
 * _headers_ - a hash of request-specific headers. (The headers sent in the
-request will be included as well, with request-specific headers taking
+request will be included as well, with operation-specific headers taking
 precendence.)
-* _options_ - a hash of additional batch request options. There are currently
-none supported, but we plan to introduce some for dependency management,
-supressing output, etc. in the future.
 
-The Batch API endpoint itself (which lives at POST /batch) takes the
-following arguments:
+These individual operations are supplied as the "ops" parameter in the
+overall request.  Other options include:
 
-* _ops_ - an array of operations to perform, specified as described above.
 * _sequential_ - execute all operations sequentially, rather than in parallel.
-*THIS PARAMETER IS CURRENTLY REQUIRED AND MUST BE SET TO TRUE.* (In the future
-we'll offer parallel processing by default, and hence this parameter must be
-supplied in order topreserve expected behavior.
+*This parameter is currently REQUIRED and must be set to true.* (In the future
+the Batch API will offer parallel processing for thread-safe apps, and hence
+this parameter must be supplied in order to explicitly preserve expected
+behavior.)
 
-Other options may be defined in the future.
+Other options may be provided in the future for both the global request
+and individual operations.
 
-Users must be logged in to use the Batch API.
+### Responses
 
-The Batch API returns an array of results in the same order the operations are
-specified. Each result contains:
+The Batch API will always return a 200, with a JSON body containing the
+individual responses under the "results" key.  Those responses, in turn,
+contain the same main components of any HTTP response:
 
 * _status_ - the HTTP status (200, 201, 400, etc.)
 * _body_ - the rendered body
 * _headers_ - any response headers
-* _cookies_ - any cookies set by the request. (These will in the future be
-pulled into the main response to be processed by the client.)
+
+### Errors
 
 Errors in individual Batch API requests will be returned inline, with the
-same status code and body they would return as individual requests. If the
-Batch API itself returns a non-200 status code, that indicates a global
-problem:
+same status code and body they would return as individual requests.
 
-* _403_ - if the user isn't logged in
-* _422_ - if the batch request isn't properly formatted
-* _500_ - if there's an application error in the Batch API code
+If the Batch API itself returns a non-200 status code, that indicates a global
+problem.
 
-** Examples **
+## Why a Batch API?
 
-Given the following request:
+Batch APIs, though unRESTful, are useful for reducing HTTP overhead
+by combining requests; this is particularly valuable for mobile clients,
+which may generate groups of offline actions and which desire to
+reduce battery consumption while connected by making fewer, better-compressed
+requests.
 
-```ruby
-{
-  ops: [
-         {
-            method: "post",
-            url: "/resource/create",
-            args: {title: "bar", data: "foo"}
-          },
-          {
-            method: "get",
-            url: "/other_resource/123/connections"
-          },
-          {
-            method: "get",
-            url: "/i/gonna/throw/an/error",
-            header: { some: "headers" }
-          }
-       ]
-}
-```
+### Why not HTTP Pipelining?
+
+HTTP pipelining is an awesome and promising technology, and would provide a
+simple and effortless way to parallel process many requests; however, using
+pipelining raised several issues for us, one of which was a blocker:
+
+* [Lack of browser
+support](http://en.wikipedia.org/wiki/HTTP_pipelining#Implementation_in_web_browsers):
+a number of key browsers do not yet support HTTP pipelining (or have it
+disabled by default).  This will of course change in time,
+but for now this takes pipelining out of consideration.  (There a similar but
+more minor issue
+with [many web
+proxies](http://en.wikipedia.org/wiki/HTTP_pipelining#Implementation_in_web_proxies).)
+* The HTTP pipelining specification states that non-idempotent requests (e.g.
+[POST](http://en.wikipedia.org/wiki/HTTP_pipelining) and
+[in some
+descriptions](http://www-archive.mozilla.org/projects/netlib/http/pipelining-faq.html) PUT)
+shouldn't be made via pipelining.  Though I have heard that some server
+implementations do support POST requests (putting all subsequent requests on
+hold until it's done), for applications that submit a lot of POSTs this raised
+concerns as well.
+
+Given this state of affairs -- and my desire to hack up a Batch API gem :P --,
+we decided to implement an API-based solution.
+
+### Why this Approach?
+
+There are two main approaches to writing batch APIs:
+
+* A limited, specialized batch endpoint (or endpoints), which usually handles
+  updates and creates.  DHH sketched out such a bulk update/create endpoint
+  for Rails 3.2 [in a gist](https://gist.github.com/981520) last year.
+* A general-purpose RESTful API that can handle anything in your application,
+  a la the Facebook Batch API.
+
+The second approach, IMO, minimizes code duplication and complexity. Rather
+than have two systems that manage resources (or a more complicated one that
+can handle both batch and individual requests), we simply route requests as we
+always would.
 
-You'd get the following back:
+This solution has several specific benefits:
 
-```ruby
-  [
-    {status: 201, body: "{json:\"data\"}", headers: {}, cookies: {}},
-    {status: 200, body: "[{json:\"data\"}, {more:\"data\"}]", headers: {}, cookies: {}},
-    {status: 500, body: "{error:\"message\"}", headers: {}, cookies: {}},
-  ]
-```
+* Less complexity - non-batch endpoints don't need any extra code, which means
+  less to maintain on your end.
+* Complete flexibility - as you add new features to your application,
+  they become immediately and automatically available via the Batch API.
+* More RESTful - as individual operations are simply actions on RESTful
+  resources, you preserve an important characteristic of your API.
 
-** Implementation**
+As well as the general benefits of all batch operations:
 
-For each request, we:
-* attempt to route it as Rails would (identifying controller and action)
-* create a customized request.env hash with the appropriate details
-* instantiate the controller and invoke the action
-* parse and process the result
+* Reuse of state - user authentication, request stack processing, and
+  similar processing only needs to be done once.
+* Better for clients - clients need to make fewer requests, as described above.
+* Parallelizable - in the future, we could run requests in parallel (if
+  our app is thread-safe).  Clients would be able to explicitly specify
+  dependencies between operations (or simply run all sequentially).  This
+  should make for some fun experimentation :)
 
-The overall result is then returned to the client.
+There's only one downside I can think of to this approach as opposed to a
+specialized endpoint:
 
-**Background**
+* Reduced ability to optimize - unlike a specialized API endpoint, each request
+  will be treated in isolation, which makes it harder to optimize the
+  underlying database queries via more efficient (read: complicated) SQL logic.
+  (Better identity maps would help with this, and since the main pain point
+  this approach addresses is at the HTTP connection layer, I submit we can
+  accept this.)
 
-Batch APIs, though unRESTful, are useful for reducing HTTP overhead
-by combining requests; this is particularly valuable for mobile clients,
-which may generate groups of offline actions and which desire to
-reduce battery consumption while connected by making fewer, better-compressed
-requests.
+## Implementation
 
-Generally, such interfaces fall into two categories:
+The Batch API is implemented as a Rack middleware.  Here's how it works:
 
-* a set of limited, specialized instructions, usually to manage resources
-* a general-purpose API that can take any operation the main API can
-handle
+First, if the request isn't a batch request (as defined by the endpoint and
+method in BatchApi.config), it gets processed normally by your app.
 
-The second approach minimizes code duplication and complexity. Rather than
-have two systems that manage resources (or a more complicated one that can
-handle both batch and individual requests), we simply route requests as we
-always would.
+If it is a batch request, we:
+* Read and validate the parameters for the request, constructing a
+  representation of the operation.
+* Compile a customized Rack environment hash with the appropriate parameters,
+  so that your app interprets the request as being for the appropriate action.
+  (This is requires a bit of extra processing for Rails.)
+* Send each request up the middleware stack as normal, collecting the results.
+  Errors are caught and recorded appropriately.
+* Send you back the results.
 
-This approach has several benefits:
+At both the batch level (processing all requests) and the individual operation
+request, there is an internal, customizable midleware stack that you can
+customize to insert additional custom behavior, such as handling authentication
+or decoding JSON bodies for individual requests (this latter comes
+pre-included).  Check out the lib/batch_api/internal_middleware.rb for more
+information.
 
-* Less complexity - non-batch endpoints don't need any extra code
-* Complete flexibility - as we add new features or endpoints to the API,
-they become immediately available via the Batch API.
-* More RESTful - as individual operations are simply actions on RESTful
-resources, we preserve an important characteristic of the API.
+## To Do
 
-As well as general benefits of using the Batch API:
+The core of the Batch API is complete and solid, and so ready to go that it's
+in use at 6Wunderkinder already :P
 
-* Parallelizable - in the future, we could run requests in parallel (if
-our Rails app is running in thread-safe mode), allowing clients to
-specify explicit dependencies between operations (or run all
-sequentially).
-* Reuse of state - user authentication, request stack processing, and
-similar processing only needs to be done once.
-* Better for clients - fewer requests, better compressibility, etc.
-(as described above)
-
-There are two main downsides to our implementation:
-
-* Rails dependency - we use only public Rails interfaces, but these could
-still change with major updates. (_Resolution:_ with good testing we
-can identify changes and update code as needed.)
-* Reduced ability to optimize cross-request - unlike a specialized API,
-each request will be treated in isolation, and so you couldn't minimize
-DB updates through more complicated SQL logic. (_Resolution:_ none, but
-the main pain point currently is at the HTTP connection layer, so we
-accept this.)
-
-Once the Batch API is more developed, we'll spin it off into a gem, and
-possibly make it easy to create versions for Sinatra or other frameworks,
-if desired.
+Here are some immediate tasks:
+
+* Test against additional frameworks (beyond Rails and Sinatra)
+* Write more usage docs / create a wiki.
+* Add additional features inspired by the Facebook API, such as the ability to
+  surpress output for individual requests, etc.
+* Add RDoc to the spec task and ensure all methods are documented.
+* Research and implement parallelization and dependency management.
+
+## Thanks
+
+To 6Wunderkinder, for all their support for this open-source project, and their
+general awesomeness.
+
+To Facebook, for providing inspiration and a great implementation in this and
+many other things.
+
+To [JT Archie](http://github.com/jtarchie) for his help and feedback.
+
+## Issues? Questions? Ideas?
+
+Open a ticket or send a pull request!

data/spec/dummy/README.rdoc

@@ -0,0 +1,261 @@
+== Welcome to Rails
+
+Rails is a web-application framework that includes everything needed to create
+database-backed web applications according to the Model-View-Control pattern.
+
+This pattern splits the view (also called the presentation) into "dumb"
+templates that are primarily responsible for inserting pre-built data in between
+HTML tags. The model contains the "smart" domain objects (such as Account,
+Product, Person, Post) that holds all the business logic and knows how to
+persist themselves to a database. The controller handles the incoming requests
+(such as Save New Account, Update Product, Show Post) by manipulating the model
+and directing data to the view.
+
+In Rails, the model is handled by what's called an object-relational mapping
+layer entitled Active Record. This layer allows you to present the data from
+database rows as objects and embellish these data objects with business logic
+methods. You can read more about Active Record in
+link:files/vendor/rails/activerecord/README.html.
+
+The controller and view are handled by the Action Pack, which handles both
+layers by its two parts: Action View and Action Controller. These two layers
+are bundled in a single package due to their heavy interdependence. This is
+unlike the relationship between the Active Record and Action Pack that is much
+more separate. Each of these packages can be used independently outside of
+Rails. You can read more about Action Pack in
+link:files/vendor/rails/actionpack/README.html.
+
+
+== Getting Started
+
+1. At the command prompt, create a new Rails application:
+       <tt>rails new myapp</tt> (where <tt>myapp</tt> is the application name)
+
+2. Change directory to <tt>myapp</tt> and start the web server:
+       <tt>cd myapp; rails server</tt> (run with --help for options)
+
+3. Go to http://localhost:3000/ and you'll see:
+       "Welcome aboard: You're riding Ruby on Rails!"
+
+4. Follow the guidelines to start developing your application. You can find
+the following resources handy:
+
+* The Getting Started Guide: http://guides.rubyonrails.org/getting_started.html
+* Ruby on Rails Tutorial Book: http://www.railstutorial.org/
+
+
+== Debugging Rails
+
+Sometimes your application goes wrong. Fortunately there are a lot of tools that
+will help you debug it and get it back on the rails.
+
+First area to check is the application log files. Have "tail -f" commands
+running on the server.log and development.log. Rails will automatically display
+debugging and runtime information to these files. Debugging info will also be
+shown in the browser on requests from 127.0.0.1.
+
+You can also log your own messages directly into the log file from your code
+using the Ruby logger class from inside your controllers. Example:
+
+  class WeblogController < ActionController::Base
+    def destroy
+      @weblog = Weblog.find(params[:id])
+      @weblog.destroy
+      logger.info("#{Time.now} Destroyed Weblog ID ##{@weblog.id}!")
+    end
+  end
+
+The result will be a message in your log file along the lines of:
+
+  Mon Oct 08 14:22:29 +1000 2007 Destroyed Weblog ID #1!
+
+More information on how to use the logger is at http://www.ruby-doc.org/core/
+
+Also, Ruby documentation can be found at http://www.ruby-lang.org/. There are
+several books available online as well:
+
+* Programming Ruby: http://www.ruby-doc.org/docs/ProgrammingRuby/ (Pickaxe)
+* Learn to Program: http://pine.fm/LearnToProgram/ (a beginners guide)
+
+These two books will bring you up to speed on the Ruby language and also on
+programming in general.
+
+
+== Debugger
+
+Debugger support is available through the debugger command when you start your
+Mongrel or WEBrick server with --debugger. This means that you can break out of
+execution at any point in the code, investigate and change the model, and then,
+resume execution! You need to install ruby-debug to run the server in debugging
+mode. With gems, use <tt>sudo gem install ruby-debug</tt>. Example:
+
+  class WeblogController < ActionController::Base
+    def index
+      @posts = Post.all
+      debugger
+    end
+  end
+
+So the controller will accept the action, run the first line, then present you
+with a IRB prompt in the server window. Here you can do things like:
+
+  >> @posts.inspect
+  => "[#<Post:0x14a6be8
+          @attributes={"title"=>nil, "body"=>nil, "id"=>"1"}>,
+       #<Post:0x14a6620
+          @attributes={"title"=>"Rails", "body"=>"Only ten..", "id"=>"2"}>]"
+  >> @posts.first.title = "hello from a debugger"
+  => "hello from a debugger"
+
+...and even better, you can examine how your runtime objects actually work:
+
+  >> f = @posts.first
+  => #<Post:0x13630c4 @attributes={"title"=>nil, "body"=>nil, "id"=>"1"}>
+  >> f.
+  Display all 152 possibilities? (y or n)
+
+Finally, when you're ready to resume execution, you can enter "cont".
+
+
+== Console
+
+The console is a Ruby shell, which allows you to interact with your
+application's domain model. Here you'll have all parts of the application
+configured, just like it is when the application is running. You can inspect
+domain models, change values, and save to the database. Starting the script
+without arguments will launch it in the development environment.
+
+To start the console, run <tt>rails console</tt> from the application
+directory.
+
+Options:
+
+* Passing the <tt>-s, --sandbox</tt> argument will rollback any modifications
+  made to the database.
+* Passing an environment name as an argument will load the corresponding
+  environment. Example: <tt>rails console production</tt>.
+
+To reload your controllers and models after launching the console run
+<tt>reload!</tt>
+
+More information about irb can be found at:
+link:http://www.rubycentral.org/pickaxe/irb.html
+
+
+== dbconsole
+
+You can go to the command line of your database directly through <tt>rails
+dbconsole</tt>. You would be connected to the database with the credentials
+defined in database.yml. Starting the script without arguments will connect you
+to the development database. Passing an argument will connect you to a different
+database, like <tt>rails dbconsole production</tt>. Currently works for MySQL,
+PostgreSQL and SQLite 3.
+
+== Description of Contents
+
+The default directory structure of a generated Ruby on Rails application:
+
+  |-- app
+  |   |-- assets
+  |       |-- images
+  |       |-- javascripts
+  |       `-- stylesheets
+  |   |-- controllers
+  |   |-- helpers
+  |   |-- mailers
+  |   |-- models
+  |   `-- views
+  |       `-- layouts
+  |-- config
+  |   |-- environments
+  |   |-- initializers
+  |   `-- locales
+  |-- db
+  |-- doc
+  |-- lib
+  |   `-- tasks
+  |-- log
+  |-- public
+  |-- script
+  |-- test
+  |   |-- fixtures
+  |   |-- functional
+  |   |-- integration
+  |   |-- performance
+  |   `-- unit
+  |-- tmp
+  |   |-- cache
+  |   |-- pids
+  |   |-- sessions
+  |   `-- sockets
+  `-- vendor
+      |-- assets
+          `-- stylesheets
+      `-- plugins
+
+app
+  Holds all the code that's specific to this particular application.
+
+app/assets
+  Contains subdirectories for images, stylesheets, and JavaScript files.
+
+app/controllers
+  Holds controllers that should be named like weblogs_controller.rb for
+  automated URL mapping. All controllers should descend from
+  ApplicationController which itself descends from ActionController::Base.
+
+app/models
+  Holds models that should be named like post.rb. Models descend from
+  ActiveRecord::Base by default.
+
+app/views
+  Holds the template files for the view that should be named like
+  weblogs/index.html.erb for the WeblogsController#index action. All views use
+  eRuby syntax by default.
+
+app/views/layouts
+  Holds the template files for layouts to be used with views. This models the
+  common header/footer method of wrapping views. In your views, define a layout
+  using the <tt>layout :default</tt> and create a file named default.html.erb.
+  Inside default.html.erb, call <% yield %> to render the view using this
+  layout.
+
+app/helpers
+  Holds view helpers that should be named like weblogs_helper.rb. These are
+  generated for you automatically when using generators for controllers.
+  Helpers can be used to wrap functionality for your views into methods.
+
+config
+  Configuration files for the Rails environment, the routing map, the database,
+  and other dependencies.
+
+db
+  Contains the database schema in schema.rb. db/migrate contains all the
+  sequence of Migrations for your schema.
+
+doc
+  This directory is where your application documentation will be stored when
+  generated using <tt>rake doc:app</tt>
+
+lib
+  Application specific libraries. Basically, any kind of custom code that
+  doesn't belong under controllers, models, or helpers. This directory is in
+  the load path.
+
+public
+  The directory available for the web server. Also contains the dispatchers and the
+  default HTML files. This should be set as the DOCUMENT_ROOT of your web
+  server.
+
+script
+  Helper scripts for automation and generation.
+
+test
+  Unit and functional tests along with fixtures. When using the rails generate
+  command, template test files will be generated for you and placed in this
+  directory.
+
+vendor
+  External libraries that the application depends on. Also includes the plugins
+  subdirectory. If the app has frozen rails, those gems also go here, under
+  vendor/rails/. This directory is in the load path.