jimcar/orchestrate-api — pull request #12 by mattly (2014-06-12 01:01:00+00:00)
Title: Release 0.6 cleanup

This closes #26, and #32, in addition to the other new features.

I'm planning to push the release tomorrow. From the Readme:

- **BACKWARDS-INCOMPATIBLE** Reworked Client constructor to take API key and
optional Faraday configuration block. See 9045ffc for details.
- Migrated documentation to YARD
- Provide basic response wrappers specific to generic request types.
- Raise Exceptions on error response from Orchestrate API.
- Remove custom logger in favor of the option to use Faraday middleware.
- Accept Time/Date objects for Timestamp arguments to Event-related methods.

The backwards-incompatible change to the Client constructor was, I feel, eventually necessary and desirable. We've gotten rid of another unnecessary class (Config), and aren't artificially keeping track of a global in the "default". The client will need to be instantiated during an application's setup, and stored somewhere, similar to how the [Ruby Redis](https://github.com/redis/redis-rb) library works.

An advanced rubyist will know what to do – The client is an entrance to something else, and they'll cache it in a module's constant or something. A newbie might hae more trouble – they'll want to treat it like an ActiveRecord class that's effectively a hidden "global" into their database.

This approach is more flexible, lends itself to someone interfacing with multiple Orchestrate Applications in the same code easily (try _that_ with ActiveRecord sometime), and with the next release I'm planning a much richer class-system based around `Orchestrate::Application`, and there will be facilities for having a "default" application in this manner.