orchestrate-io/orchestrate-ruby — pull request #16 by mattly (2014-05-14 19:37:36+00:00)
Title: base client cleanup

This is based on the faraday integration. The actual changeset is much smaller than it will appear here, until the faraday branch gets merged.

Pursuant to #10, this starts an effort to make reliable, explicit use of the function signatures to generate our http requests, instead of implicitly creating options from a magic hash. It no longer requires passing in query strings, options per-method are turned into query parameters as needed. Where it makes sense to, I've made the method names similar to the other clients, typically using the Go client as a canonical source.

Furthermore, by getting rid of the API::Procedural module and API::Request class, documentation and "where to find it" should end up being a lot more straightforward. Perhaps in the future we can move those methods back out into an "API v0" module, but for now I think this is a good move. There is less boilerplate, and by extension, we can easily have the request use the client's configuration and therefore close #12.

For now I have removed API::Response in favor of Faraday::Response. For working with adapters such as EM::HTTP this will prove beneficial until we figure out ways for doing f.e. callback passing. The helpers around accessing things such as the Etag header and items from the response body don't make sense to me in a generic response handler, because those things aren't present on **all** responses. The DSL I intend to create will provide nice wrappers around these.

The client now uses Faraday middleware to handle parsing JSON response bodies, and handles JSON serialization of the outgoing request bodies.

Next steps, I can help Jim with updating his rails plugin, and get started on the more DSL-ish stuff I'd like to do, also described in a comment in #10.