lesscode.org

With all this talk about High and Low REST, I noticed something in a post by Mark Nottingham:

Don has effectively made the observation that a lot of other people (especially of the Web services sort) have made; while the benefits of GET’s transparency are obvious, they’re less apparent for PUT and DELETE, so why not just take the easy (lo) road and use POST?

I think there are two answers; 1) hopefully, we’ll have some concrete benefits for that transparency some day (think offline), and 2) thinking in terms of GET/PUT/DELETE first — using POST only as an escape hatch — leads you down a path where your application will be using transparent methods a lot more than opaque POSTs.

I’ll use my first post here to repeat the ideas from Bill’s post…

I think a cargo cult of REST has indeed emerged, and I’m seeing evidence of it on the ground, far from SOA discussions. I’m seeing REST evoked as something that is inherently good. I’m seeing people ask for REST support in their frameworks. I usually know what they mean, but their requests seem to be driven by the truthiness of REST, not the utility.

For instance, I often get annoyed with URI design discussions, where people put great importance into abstract design issues that no one else will notice or care about. In HTTP (and REST) URIs are supposed to be opaque strings, so why the obsession? I call bike shed. People are tackling the pointless decisions first, because they are low-stake and easy to think about. It also comes from an inversion of logic: good things are generally aesthetically pleasing; but many things that are aesthetically pleasing are superfluous and distracting.

What’s useful is that REST design doesn’t promise anything more than it can deliver. It doesn’t promise anything general about the body of the response (except I suppose that Content-type and other metadata will be accurate). It doesn’t promise anything about the URI. The use of verbs is in part to make the URI more opaque, so instead of rewriting the URI to express new actions, you use different verbs on the same URI. GET actually means something to intermediaries. POST, PUT, and DELETE only really mean something to humans. Which is okay, but it’s not interesting architecture.

It’s not bad to use these verbs, it’s just not particularly useful. I think High REST may be the result of people who just can’t help but make architecture. Low REST is people who are recognizing emergent architecture. REST isn’t a new idea, it is the recognition of the good ideas that are already around us. And like design patterns, the description is turning into prescription, and as with patterns we are seeing people use REST to justify premature architecture — probably a much worse sin than permature optimization.

I look at a protocol like OpenID which is wedded to HTTP and HTML — and even intimately connected to those poorly-specified browsers that we all can’t help but hate — and I think that’s great architecture. It’s not great because it is pretty underneath (it isn’t), it is great because it solves a hard problem inside fixed constraints without exceeding scope. It’s RESTful at heart, but not RESTful in form.

If there aren’t concrete benefits to using PUT or DELETE over POST, then why should we care? What hard problem is made easy? High REST seems to be uncovering non-problems.

I’d like to follow up Ryan’s post with a quick note on what they call high REST. The definition seems to be using GET/POST/PUT/DELETE. Those are the four significant methods in RFC2616, but every other version of HTTP has contained additional methods, and there are no widely deployed applications that operate that way. WebDAV is a bad example, since it doesn’t use POST, and defines many additional methods. LOCK, COPY, MOVE, and other methods are required to make it a useful protocol. The Atom protocol uses only those four methods, but it hasn’t seen wide deployment (though it may).

This reality sort of pokes a hole in the argument that “high REST” standardizes what is already known to work. That doesn’t mean it won’t work, but GET/POST/PUT/DELETE advocates who claim they are pointing out the obvious are actually making a religious argument, and that poor thesis is playing the role of C-3PO in the Ewok village. It’s unproven technology, and it should be viewed with healthy skepticism.

I’ve been actively developing software for the past 17 - 18 years. When I began, back in 1987, the recommended language of choice was C. The rationale at that time being that C is a language that closely and faithfully mimics the inner workings of the underlying low level machinery.

Obsession with the infrastructure. Yes, computing infrastructure is fascinating. But what is a computer?

Mainframe is the Computer

If you asked IBM 20 years ago what is a computer, they’d tell you that the mainframe is the computer. They were selling mainframes at that time, and to them every problem looked like a nail.

Network is the Computer

At around the same time, Sun Microsystems attempted to take over the world with their slogan “Network is the computer”. The exact opposite of mainframes. Great.

Database is the Computer

Also, another big-ass vendor, Oracle, had to make an attempt to take over the world with their vision of a database being the computer. Yes, databases are fun.

Desktop is the Computer

Finally, Microsoft took a swing at it by announcing that desktop is the king. Yes, desktop is so cool, so sexy. And, as it became more and more affordable, it really started taking over the world by the storm.

Who cares?

Really, honestly, who cares? Why should we care? Why should we act as foot soldiers (unpaid foot soldiers, mind you) for those vendors? It’s like us paying them to bombard us with their advertising.

I must say that I’m at a loss when it comes to why are we, 20 years after these ugly vendor wards started raging, still caught in the debate. What’s in it for us? Yes, we all understand what’s in it for the vendors. But, why should we care about helping them see that their definition, their slogan wins?

It’s like getting caught in trying to define what is electricity. The producers of electric power claim that electricity is turbines that generate it. The producers of copper wires claim that electricity is wires. The producers of light bulbs claim that electricity is the end-point, the light bulbs that deliver incandescent light to our homes.

But do we, as consumers, care whose vision wins? No. All we care for is that when we turn the switch on, the room gets filled with light.

Who is Serving Whom?

My understanding has always been that we have invented computers to serve us. Now I see that all we’re doing is expending inordinate amounts of time serving them. I don’t see any justification for why this should be so, and I therefore proclaim here that it’s high time that we cease and desists and insist that all this computing infrastructure start serving our needs.

But in order for that to happen, we first must stop obsessing about the computing infrastructure. It’s about time we get over it.

Applications are Infrastructure

Just so that we’re clear on what encompasses the computing infrastructure, I’d like to point out here that it’s not only about the hardware and the middleware and the operating systems, databases, and frameworks. Application software also counts.

We all know how much we tend to obsess about the applications. Many of us find a number of software applications fascinating. Well, snap out of it! Stop serving your favorite applications, and start looking into how to make those applications serve you.

You should start looking at applications as being a kind of anomaly, a necessary evil produced out of dire necessity in the attempt to cover the gaping holes in the existing computing machinery. Applications are superfluous, and will eventually recede into the background. Today, they hold the center stage, and many people obsess about them. But that is bound to change.

Once we grow up and stop obsessing over the infrastructure, we’ll finally be ready to embrace the wonderful world of computing on our own terms. This is similar to how we had to grow up and embrace the wonderful world of printed word. It wasn’t easy, and it took some serious schooling, but eventually we managed to pull it off.

Yes, there are still pockets of illiteracy even among the most developed countries, but these are negligible compared to the overwhelming literacy that is now the cornerstone of our culture.

A longish soul-searching blurb continuing the ‘database manages the meaning’ debate:

Confessions of a Former Data Integrity Addict

I’ve started writing a blurb for lesscode.org on some of the fundamental axioms of web information processing, but my pen took me down the rambling path and I’ve ended up with a longish article on my hands. So instead of clogging the lesscode.org’s bandwidth, I’ve posted it on my blog.

If you’re interested in examining certain long-standing challenges related to the web computing, and how Ruby and Rails approach the solution, you may find some meat in there.

P.S. I’ll be blunt and admit right away that I’m slamming the role of RDBMS in the web architecture, so I’m not really expecting that most people will agree with my analysis. Oh well, c’est la vie…