[ANN] rest-core 0.8.0 released

# rest-core <https://github.com/cardinalblue/rest-core>

by Cardinal Blue <http://cardinalblue.com>

## DESCRIPTION:

Modular Ruby clients interface for REST APIs

There has been an explosion in the number of REST APIs available
today.
To address the need for a way to access these APIs easily and
elegantly,
we have developed [rest-core], which consists of composable middleware
that allows you to build a REST client for any REST API. Or in the
case of
common APIs such as Facebook, Github, and Twitter, you can simply use
the
dedicated clients provided by [rest-more].

[rest-core]: http://github.com/cardinalblue/rest-core
[rest-more]: http://github.com/cardinalblue/rest-more

## INSTALLATION:

    gem install rest-core

Or if you want development version, put this in Gemfile:

    gem 'rest-core', :git => 'git://github.com/cardinalblue/rest-
core.git',
                     :submodules => true

If you just want to use Facebook or Twitter clients, please take a
look at
[rest-more] which has a lot of clients built with rest-core.

[rest-more]: http://github.com/cardinalblue/rest-more

## CHANGES:

### rest-core 0.8.0 -- 2011-11-29

Changes are mostly related to OAuth.

### Incompatible changes

* [OAuth1Header] `callback` is renamed to `oauth_callback`
* [OAuth1Header] `verifier` is renamed to `oauth_verifier`

* [Oauth2Header] The first argument is changed from `access_token` to
  `access_token_type`. Previously, the access_token_type is "OAuth"
which
  is used in Mixi. But mostly, we might want to use
"Bearer" (according to
  [OAuth 2.0 spec]) Argument for the access_token is changed to the
second
  argument.

* [Defaults] Now we're no longer call `call` for any default values.
  That is, if you're using this: `use s::Defaults, :data => lambda{{}}
`
  that would break. Previously, this middleware would call `call` on
the
  lambda so that `data` is default to a newly created hash. Now, it
would
  merely be default to the lambda. To make it work as before, please
define
  `def default_data; {}; end` in the client directly. Please see
  `OAuth1Client` as an example.

[OAuth 2.0 spec]: http://tools.ietf.org/html/draft-ietf-oauth-v2-22

### Enhancement

* [AuthBasic] Added a new middleware which could do [basic
authentication].

* [OAuth1Header] Introduced `data` which is a hash and is used to
store
  tokens and other information sent from authorization servers.

* [ClientOauth1] Now `authorize_url!` accepts opts which you can pass
  `authorize_url!(:oauth_callback => 'http://localhost/callback')`.

* [ClientOauth1] Introduced `authorize_url` which would not try to ask
  for a request token, instead, it would use the current token as the
  request token. If you don't understand what does this mean, then
keep
  using `authorize_url!`, which would call this underneath.

* [ClientOauth1] Introduced `authorized?`
* [ClientOauth1] Now it would set `data['authorized'] = 'true'` when
  `authorize!` is called, and it is also used to check if we're
authorized
  or not in `authorized?`

* [ClientOauth1] Introduced `data_json` and `data_json=` which allow
you to
  serialize and deserialize `data` with JSON along with a `sig` to
check
  if it hasn't been changed. You can put this into browser cookie.
Because
  of the `sig`, you would know if the user changed something in data
without
  using `consumer_secret` to generate a correct sig corresponded to
the data.

* [ClientOauth1] Introduced `oauth_token`, `oauth_token=`,
  `oauth_token_secret`, `oauth_token_secret=`, `oauth_callback`,
  and `oauth_callback=` which take the advantage of `data`.

* [ClientOauth1] Introduced `default_data` which is a hash.

[basic authentication]: http://en.wikipedia.org/wiki/Basic_access_authentication