Open Up a Can of API Awesomeness

Adobe Kuler – a cool app that has nothing to do with this blog post…

The past week or so we have been learning to work with API’s.

In case you aren’t familiar with what an API is… basically it is a way to connect your app to another application and let your users do things on your app that are also tied to the “mother” app – the one whose API you are tying into.

For example. I could build an application that allows a user to sign in and make a list of things that they need to do. Then I could use the Twitter API to tweet those “things to do” out as the hit a “due_date.” If the person is an avid Twitter person this might help them remember to do some things that wouldn’t otherwise be remembered.

So… that isn’t the best example above. In case that doesn’t make sense let me hit you with another example.

I could also build an accountability application that would allow users to sign in… set the thing they want to get done and a due date. Then they could also set goals within that time frame. As each goal comes due… If they have completed the goal we could use Twitter’s API to tweet out a tweet that says “congrats to “#{user}” for completing “#{the_sub_goal}”. Or if they didn’t complete the goal we could tweet out on their behalf saying “consider encouraging “#{user}” to completing “#{the_sub_goal}”.

Again, that may not be the best example… but the idea is that the user is working on my application and what they are doing while they are on my application is being processed and triggering actions for them on another application.

It’s the Power of the Internet

Here is the thing though. This is the power of the internet. The ability to interact with other users and other applications is the very thing that I love about the internet.

Using an API allows me to get outside of just my applications system. Suddenly I am opening the possibilities of who may be interested in using my application, simply because it is tied to what they are already using. Even better if my application allows the user to do something that isn’t normally available to them in the application that my app talks to.

Ruby on Rails may be best used as an API Framework

Ruby on Rails (the language and framework that I’ve been working on learning for the past eight weeks) is really powerful. In a nutshell it can do everything from creating data to transferring it to a database, it can also send out emails at specific moments in different processes, it also will render views and provides a way to bring your database data into the front end.

Ruby on Rails is a powerful “do it all” type of monster.

But… and I believe that this is an important distinction. (I could also be totally ignorant and way off base.) Ruby on Rails is kind of slow (especially on the front end). It is however rock solid on the back-end and performs tasks really well and really quickly.

So I think, and here is where I may be wrong, Ruby on Rails may be best used as an  API framework. If we were to build a Backbone.js (or any other one) front end that would tie into our Ruby on Rails back-end (basically using .ajax to make get, post, delete, etc requests) then we may just have found a match made in heaven.

The front end would look great and move exactly like we want it to. It would be talking to the backend and performing tasks back there, but it wouldn’t have to be making database calls for every single addition/deletion.

And that is where I’m at. I think that is the route that we want to go, but I’m not entirely sure how to get there just yet.

That’s what the next couple weeks of class are supposed to help me with. I think.