Back to Blog

What the Heck is this REST Stuff Anyway?

Ben Kittrell
08/23/2006 01:58PM

There's been a lot of buzz around REST lately, but what exactly is this talk all about? Like Danger said, when you search for information on REST, you mainly find people describing it as "Not RPC". Well that's fine but what's wrong with RPC? I did a little research and I think I can bring some light to those of you that are like me, and just don't get it.

I first heard of REST a few years ago, and I thought it was just an alternative to SOAP. Well it is, kinda, but it's much more than that. Recently folks have been talking about REST-full applications, so what does REST mean in the context of web applications? Basically it means that instead of using keywords in your URL to specify which action to call (http://garbageburrito.com/messages/update), you use the existing HTTP protocol methods (PUT- http://garbageburrito.com/messages). HTTP has four methods, POST, GET, PUT, and DELETE. Most of us only deal with POST and GET, but the others are there, just begging for attention. The idea is that these four methods map directly to CRUD operations CREATE, READ, UPDATE and DELETE. I'm not going to go into this much yet, because that's where I started to get confused.

Now that's REST for web applications, but where did REST come from? All of this started from Roy Fielding's dissertation on Architectural Styles [1]. He set out to define an architectural style for web application development similar to existing software engineering paradigms. REST stands for Representational State Transfer. After reading Roger L. Costello's Building Web Services the REST Way [2], it seems to me like REST at its core is just a description of how the web works today. Transferring states through different representations of content. But overall, REST is a way of adding constraints to your architecture in order to increase development efficiency. Those that have used Rails know what I'm talking about. When you add constraints, you start to forget about the things they constrain, which is a good thing.

Like I said before, REST is commonly associated with Web Services, which is where everything started to make sense for me. One of the common problems with Web Services is discovering them and how to use them. When using an RPC protocol like SOAP, you have to know the resource, and which remote procedure to call. Since most service fall into the CRUD paradigm anyway, and each CRUD operation can map to an individual HTTP method, why not exploit the existing protocol? This way you just have to know the resource (http://garbageburrito.com/users) and it will behave differently based on which HTTP method is used.

This brings me full circle to my original question, what's wrong with RPC? Why bother using this REST approach when we're already comfortable with our current methods? What does it give me? Using a REST-full approach gives you constraints. Since there are only four HTTP methods, and these map to CRUD operations, this means that you can only create, read, update and delete resources. It forces you to make your entire application CRUD. Just think about that, how could you write an application if there was only CRUD?

I'll leave it at that, because appreciating REST requires you to appreciate the value of constraints. Just like Rails, it's not for everyone, but it is a new milestone in the continuous quest for web application standards.

References

Comments

Danger 08/24/2006 04:47AM

What an incredibly helpful introduction to REST. Thanks for this Ben. I've been trying to do REST for a while now but I totally learned new stuff from what you just wrote.

chris 08/24/2006 05:19PM

great intro article! I've been doing a lot with REST this week since danger's blog post and you've done a great job in laying out the basics for people. It's quite a paradigm shift in thinking but I think it gets easier with time and practice!

I've been thinking about it a lot in terms of resources, and actions that can be preformed on those resources. An anology I've been using with myself is that of a book. We can read a book, an author writes a book, publishers edit books and fascists burn books, but they are all acting on the same thing, the book, the resource. Thus the HTTP methods are simply verbs, words to describe the action performed on the subject - the subject remains the same, but it is the way we approach that subject that defines what it is that we get back, or the result of the action. So a GET request to articles/3 wil return the article with ID 3, whereas a DELETE request to article/3 will delete the article with ID 3 (so long as you have the correct authorisation to do so).

Anyway, great article and hopefully it'll set more people on the road to RESTful Rails! :0)

thabenksta 08/24/2006 05:26PM

Chris,

You're absolutely right, thinking in terms of resources is the natural progression of using REST. In fact DHH is working on ActiveResource, which I think will basically allow you to easily turn your controllers into an api.

Thanks for reading guys.

Bob Dawson 02/24/2018 03:56PM

Like I said before, REST is commonly associated with Web Services, which is where everything started <a href="http://chinesebuffetnearmenow.net/">best asian food near me</a> to make sense for me

Post a Comment