Rest-core 0.8.0 released


by Cardinal Blue


Modular Ruby clients interface for REST APIs

There has been an explosion in the number of REST APIs available
To address the need for a way to access these APIs easily and
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
dedicated clients provided by rest-more.


gem install rest-core

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

gem 'rest-core', :git => '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-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”
    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

  • [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
    lambda so that data is default to a newly created hash. Now, it
    merely be default to the lambda. To make it work as before, please
    def default_data; {}; end in the client directly. Please see
    OAuth1Client as an example.


  • [AuthBasic] Added a new middleware which could do basic

  • [OAuth1Header] Introduced data which is a hash and is used to
    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
    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
    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
    if it hasn’t been changed. You can put this into browser cookie.
    of the sig, you would know if the user changed something in data
    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.