HTTP Made Simple, Part 1: The Web As A Key-Value Store
The HTTP protocol is generally poorly understood.<small>And I'm not even going to get into REST. If you really want to understand REST, read the paper by the guy who coined the term (and, not incidentally, was the principal author of the HTTP specification). Technically speaking, HTTP is a protocol that conforms to REST constraints. So we can just talk about how to use HTTP effectively and not worry too much about REST.</small> There are a variety of reasons for this, but one of them is that it's a fairly rich protocol and, consequently, writing clients and servers that take full advantage of its features is non-trivial. Naturally, developers either make use of a subset of those features or use something else entirely, like Web Sockets.<small>The danger here is that you end up implementing your own variation of the same features, such as caching. See Greenspun's Tenth Law.</small> At Panda Strike, we've tried to make it easier to fully utilize HTTP's features with Patchboard, but that presumes you already understand them. This blog post is intended to help you do that.
A Distributed Key-Value Store
The first thing to understand about HTTP is that it sees the world as a giant, distributed key-value store. The keys are URLs. And the values, called resources, can be pretty much anything. This is why the well-defined HTTP methods are the verbs
DELETE—you can get and put these values, and perhaps even delete them. There's a bit more to it than that, obviously,<small>Some of you are thinking, for example, he forgot about
POST.</small> and we'll get to that, but that's the basic idea. When you think HTTP, think key-value store, and you'll be off to a good start.
Representations Versus Resources
HTTP cleverly allows for the possibility that a given value might take different forms. For example, the same video might have different formats. Or we might have a document that can be accessed as HTML or PDF. HTTP calls these representations of a given resource. This reflects how we think about things in real life. We talk about the movie Blade Runner without clarifying whether we saw it in HD. It's still the same movie, regardless of the format. On the other hand, the director's cut would be a different resource entirely.
In this context, we can think of resources themselves as being another key-value store, where the keys are content types<small>For example,
text/html, for HTML, or
application/pdf for PDF.</small> and the values are representations. Whether we can model our applications that way or not, that's the model that HTTP provides. It's simple, elegant, and flexible. And, more importantly, it provides the foundation that HTTP uses for useful features like caching.
Until Next Time…
In our next installment, we'll explore the role of the HTTP methods in more detail.