Patrick Tulskie

Quite frankly, I’m tired of about hearing about REST.

…

So what if I started off my post with a pun?  Look you’re just going to have to deal with it.  Let’s move on.  No stop it with the face, it’s my blog and I can do what I want.

Anyhow - REST is one of those things I hear a lot of people talk about as if it is this big mystery.  Then, when you finally find someone to explain it, it turns out they have never actually used it and only understand the theory.  It’s so frustrating to the beginning Ruby on Rails developer because not everyone has a mini David Hansson in their pocket and it really is one of those things you need to see to understand.

Ok Patrick.  I’ll bite.  Let’s hear more about this.

It’s a really simple concept that I will explain abstractly at first and then I want you to forget what I said until I compare it to what you’ve probably already seen.  REST stands for Representational State Transfer.  Technically speaking, REST should be RST but since Roy Fielding coined the term in the year 2000 and he’s kind of a big deal, people tend to stick with his acronym.

The theory behind it is that your destination |object| is nothing more than a representation of that object at the time you are viewing it.  This plays extremely well into a MVC framework like Ruby on Rails since your controllers and models handle the object and the view is just how you see the object at a given point in time.  Then in the URL, you would just be using nouns to describe what you’re getting.  Sorta like this:

http://yourdomain.com/noun1/…/your_object_name

That makes no sense.

I know.  Look, it’s actually really simple.

Ok so say I have a web application that you would like to pull data from in order to handle however you’d like with a separate application you are creating.  An example might be a news site - they provide for you an RSS feed that.  The data is all the same server side but how your web browser sees it is different from how your RSS feed reader sees it so the object (the data) needs to change its form to be readable to the current application.  With me so far?

If I wrote my web application to be RESTful then your application could request the data in RSS or XML or whatever form you prefer to parse, all while maintaining a normal user’s view in their web browser.  Ah ha!  So we’re no longer web page builders - we’re data providers.  You’re now actually building page templates and writing more code to handle your data.

I’m still a little unsure about this Patrick.

I was too, so I sat down and tried it.

On my side project - www.Twexaminer.com - I made sure that my controller was pulling data from twitter and storing it into objects instead of just “building a page.”  From there I created 2 views.  One is the default HTML view that you see when you view the page from a web browser and the other is a special .xml request that gives you the output of all of the data that the application has collected.

Ex:
http://www.twexaminer.com/examiner/result/patricktulskie
-vs-
http://www.twexaminer.com/examiner/result/patricktulskie.xml

Basically I’m going to my examiner and saying “hey, give me a result” and then clarifying that it should be PatrickTulskie.  In the second example there I tell the examiner to give me the result of PatrickTulskie in XML format.

I could further expand this to make more views or representations for the same data, but for the time being I just have the 2.  In this way, I am now passing on the content using standard looking URLs that a common person can understand.  In addition, if you want to parse the data easily, there is a very intuitive way to get the data without the formatting fluff.  I am effectively passing data to your app, without the use of SOAP or any special hacks, in a format it understands just with a simple GET.  Ah ha!  Simple!

Ok now if I wanted to get fancier then I could add something to my examiner controller to handle updating of a cached result so it would look something like this… in pseudo code…

pt_object = new RestResource(http://www.twexaminer.com/examiner/result/patricktulskie)
pt_object.update

…and then pull off data from that.  This would all be handled through HTTP requests though without needing any additional layers to handle transferring XML to and from client and server.  RestResource is a hypothetical object that one could create that has a simple XML parser to make an easy to use hash out of the data.  XML parsing and generation is easy in Ruby so this just makes sense.

Ah so this is pretty sweet.

Yeah. I know.  It makes things much simpler when you’re creating something that uses my data now doesn’t it?  Go, play with it in your project and let me know what you think in the comments or on Twitter, or through email, or through facebook… or whatever.  Just make sure I get the “comment” you’re trying to convey through some medium.