Ionrock Dot Org

I have been doing a few interviews as of late for my day job and it really hasn't been going well. I'm going to go ahead and take responsibility for the fact that my interview skills need some serious work. Beyond this though, no one knows much of anything about REST and/or HTTP. While I wouldn't say I'm an expert, it is clear that my knowledge ends up faring well against most the senior developers that I've been interviewing.

The point here is not to place myself upon some kind of expert pedestal. In fact, the point is just the opposite. I'm not an expert. When I was learning PHP I heartily ignored HTTP any way I could because I felt it was a waste of time. When I was forced to edit a few Perl CGI scripts, I felt the explicit Content-Type headers were silly. Little did I know that the explicitness was not explicitness at all, but rather simply using HTTP in an application. I doubt the code I edited revealed this subtlety at the time, but, it still was an opportunity for me to dig deeper that was ignored.

In learning WSGI and Python web development, it became clear that I would need to deal with HTTP. The first part was using simple status codes. This seemed like a hassle at first. It became quickly apparent that I could use HTTP to communicate much of what I meant simply by providing a decent status code. My next big step was working with the content type. I saw very quickly why all the PHP scripts for forcing a download actually worked. In the past this was semi-understood, but now I saw the real value. I also learned about content negotiation and how powerful it could be in creating a RESTful service.

All of this was learned within the scope of the AtomPub spec writing process. I watched as folks discussed caching, URI templates and linking. It became clear how using and understanding HTTP makes creating RESTful services intuitive, simple and efficient. There is no silver bullet, but understanding RESTful Web Services does a great job of doing the most with what you have.

So, what are my suggestions for really understanding REST? The first step is realizing the world is not about CRUD. REST doesn't get you anything better than SOAP or XML-RPC in this case. One could argue that, since browsers don't support PUT and DELETE out of the box, RESTful services are more difficult. I'm not saying that RESTful CRUD is unimportant, but simply it is not the real hype.

The big deal about REST is Linked Data. When you consider the division between a resource and a representation along side using linking to define the flow of state, the stateless web becomes a more understandable application platform. You can think of resources simply as URIs and representations the file you get back from the request of the resource. This is somewhat over simplified, but more or less this is how you think about things in REST. The next thing to understand is a representation or resource is not an object. It sure can be, but it is not by default. This may seem odd from an OO perspective, but the web is a creation of documents, not objects. Sure, these documents are often compositions of object data, but from the standpoint of a RESTful service, they are all documents.

This distinction is huge because it sets expectations. You will never just assume you can point some function at a URL and magically get an object. I'm not saying you won't write a method or two to make a GET request and build an object. You will and that is fine. But the fact is, you understand that when the document changes formats, you might have to change your code. Might is the operative word here because being RESTful means making an effort to be robust.

When you think of the web in terms of documents, the work flow of how to deal with data changes. Instead of thinking in terms of an object, there is an actual document that you reference. Any sort of language specific tool you use to work with the document is separated from the document itself. When you consider manipulating something like XML, you have tools that let you maintain the document as a whole. Contrast this with ORM tools that take small pieces of data and place them in data structures. When you are talking about the web, working with documents is much simpler than thinking in terms of serialization between a view, data structure, ORM, and database.

Another area I think causes confusion and misunderstanding for REST comes from the fact that it is more functional (in the Lisp/Haskell/Erlang sense) than object oriented. Functional languages require that variables be immutable. This is a direct parallel to HTTP requests. A web application cannot pass along a reference to some object that is tethered to an instance on the server. This means programming in this fashion is only working against you.

What is interesting about REST as a movement is that it is not meant to be innovative. REST aims to analyze what is successful about the web and apply the principles to web application development. In a way, it is what folks came up with after a code review of the web. I am hoping that more people make an effort to understand REST for what it is. In many cases it really takes some effort to think in RESTful terms. This is especially true when you are accustomed to thinking in objects. Hopefully, more people will continue to catch on and see the benefits, so we can finally move on to even better misunderstood principles for the Web 3.0 code review!