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

• [1] Architectural Styles and the Design of Network-based Software Architectures - Roy Thomas Fielding (2000)
• [2] Building Web Services the REST Way - Roger L. Costello