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!