The Blog > Technology > Dropbox Ruby SDK done right

Dropbox Ruby SDK done right

November 10, 2011 by Marcin Bunsch

Dropbox Ruby SDK

We love Dropbox. We really do. Everyone on our team is using it and we think that they solved a big problem in a beautiful and elegant way.

We are now working on a *mind-blowing* integration between Base and Dropbox so we were very happy to hear about the recent updates to their API.

Excited and happy, we started working on the integration only to find out that the Dropbox API Ruby SDK is, well, let’s call it “not cool”. We love Ruby, but the SDK does not take advantage of this beautiful language!

As builders and hackers we knew that this could not stand and so we decided to write our own Ruby SDK for Dropbox.

So what’s exactly cool about our solution you might ask.

Well, here are the highlights:

  1. It’s using the oauth gem, instead of reinventing the wheel and implementing OAuth communication all over again
  2. It treats files and directories as Ruby objects with appropriate classes, on which you can perform operations (think file.copy “here”)
  3. It is thoroughly tested
  4. It’s lightweight and clean – it does not extend any of Ruby’s internals

We are all about sharing so we open sourced our Client and you can now access it on GitHub. We’ll be happy to hear your thoughts.

This entry was posted in Technology and tagged , , , . Bookmark the permalink.
  • http://cakoose.com/ Kannan Goundan

    Hi Marcin! I work at Dropbox on the API. First of all, thanks for writing your library! We’re not Ruby experts so we’re happy to learn how Real Ruby People like their libraries. There are a couple decisions we made, though, that could use some explanation.

    We were initially using the ‘oauth’ gem in HMAC mode, but were having trouble getting it to work in PLAINTEXT mode. As it turns out, OAuth’s PLAINTEXT mode is so simple that it’s actually easier to do it ourselves than to get the gem to do it.

    Also, I noticed that you store the app key and secret in global state. We deliberately chose to encapsulate things in DropboxSession and avoid global state, but I can see the argument that global state is more convenient, at least initially (the Stripe SDKs all use global state as well).

    And your preference for real classes instead of hashes is a useful datapoint for us. This was another case of us not having experience with Ruby library design. We saw some libraries that used classes and others that used hashes and sort of took a guess.

    Anyway, thanks again for writing the library. We’ll put a link to it on our SDKs page.

  • Marcin Bunsch

    Hi Kannan!

    I see your point about the global state, this design decision was based on a very common scenario – my app is associated with one app in DropBox, so I only need to enter the consumer key and secret once.

    As for classes vs hashes – I think it’s personal preference mostly, I find the syntax cleaner with objects.

    Thanks for releasing the v1 of the API, it was a lot of fun to play with! :)