# 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