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.
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.
CHANGES:
rest-core 0.8.0 – 2011-11-29
Changes are mostly related to OAuth.
Incompatible changes
-
[OAuth1Header]
callback
is renamed tooauth_callback
-
[OAuth1Header]
verifier
is renamed tooauth_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 callcall
on
the
lambda so thatdata
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.
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
usingauthorize_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 inauthorized?
-
[ClientOauth1] Introduced
data_json
anddata_json=
which allow
you to
serialize and deserializedata
with JSON along with asig
to
check
if it hasn’t been changed. You can put this into browser cookie.
Because
of thesig
, you would know if the user changed something in data
without
usingconsumer_secret
to generate a correct sig corresponded to
the data. -
[ClientOauth1] Introduced
oauth_token
,oauth_token=
,
oauth_token_secret
,oauth_token_secret=
,oauth_callback
,
andoauth_callback=
which take the advantage ofdata
. -
[ClientOauth1] Introduced
default_data
which is a hash.