August 21, 2008

Upcoming CouchDB Event in London, August 26th

Jan will be speaking about CouchDB at Erlang Training and Consulting, starting 6:30 pm. It's a free event, you are invited. Go Jan!


August 18, 2008

REST is the web, nothing more

I'm wrong. REST, as originally described, has nothing to do with POST PUT DELETE. If you look at the original paper (chapter 5), REST is simply a description of the web as it actually work as a distributed hypermedia browser platform. The paper talks alot about all the things required to send media to the clients, but almost nothing about sending data from the client to the server.

There is nothing about verbs, RPC, POST vs. PUT, idempotency, or posting resources back to the same URI from which they were gotten. I was blasting the dogma around those things but was wrong to call it REST, I was under the misconception that REST is also about those things. Lots of writing about REST seem to have this misconception as well.

Why isn't REST about these things? Because REST is a description of the web and those things don't really exist on the web. Not in any standardized way. When people start talking about something being RESTful, do they mean its how the web actually works, or how we wish it worked?

In the real world, there is a remarkable effort to ensure that a wide range of browsers can find, retrieve and understand media and content from web servers. DNS, URIs, HTTP, firewalls, proxies, caches, media types, etc are what makes the web work and that's what REST describes, but in more generic terms.

On the other hand, pretty much any time a browser POSTs a message, only one server in the whole world is supposed to understand what it means, there is no broad standardization of sending data and content to servers and how the servers are supposed to interpret it. Each server is free to implement its own interface, and they generally do. While there has been efforts to make the web into a standardized read/write platform, nothing has caught on in a big way.

So is POST as RPC RESTful? The practice of roll-your-own POST format is alive and well and successful on the web, and therefore, by definition, RESTful. As long as you are not abstracting HTTP away (and ignoring what HTTP gives you for free), your are probably using it RESTfully.

Glad we cleared that up.


August 15, 2008


Strangely, OS X spell check doesn't recognize kerfluffle as a word, but it does recognize klerfmuffle (suggested after I typed in klerfluffle). But klerfmuffle isn't a word, not even in Google. Until now that is.


"The web is built on REST. Therefore REST is good" Bullshit

The web is built on GET and POST verbs, not the RESTful GET, PUT and DELETE (and sometimes POST) verbs.

The only thing that's RESTful about 99% of the web is that it uses GET (even then many applications use GET wrong). The argument that REST is great because it provides standardized caching support, well that pretty much only applies to GET requests anyway, what about PUT and DELETE?

It's not verbs that make it all work, it's URLs and HTTP. HTTP 1.0 is so damn simple to be almost too simple. 1.1 fixed its biggest deficiencies without adding much complexity, and now HTTP is a transport and protocol that does its job just well enough to not get in the way. And that's what the web is built on.


August 14, 2008

REST, I just don't get it

As the guy who created CouchDB, I should be a big cheerleader for RESTful architectures. But the truth is, I just don't get it.

For CouchDB, REST makes absolutely insanely perfect sense. Read a document, edit, put the document back. Beautiful. But for most applications, enterprise or not, I don't see what the big win is.

I know what is wrong with SOAP, and it has everything to do with unnecessary complexity and solving the same problems twice. But what is the big advantage of making all your calls into GET PUT and DELETE? If POST can handle everything you need, then what's the problem?

I guess what I mean to say is just because SOAP is a disaster, doesn't somehow make REST the answer. Simpler is better, and REST is generally simpler than SOAP. But there is nothing wrong with a plain old POST as an RPC call. If its easy to make all your calls conform to the RESTful verb architecture, then that's good, I guess. But if not, then just use a POST as an RPC call, keep it as simple as possible and be done with it. And don't spend another minute worrying about being RESTful or not.


August 12, 2008

Quick Blog Entry

I've been really busy and just not in a blogging mood lately. But I'm going to force myself to write a blog post for 15 minutes. This is it. I'm a slow typist.

CouchDB development is going well. We have more contributors and are about to add another project member. We are about to release a 0.8.1, which I think will be a very solid and useable release. The trunk is usually in good shape, but unpredictable. You might encounter serious bugs. Be warned.

The interest in CouchDB is impressive for a still immature project. And like most open source projects, its all word of mouth. We don't have a PR or marketing department. Except for Jan :)

Right now I'm working on a few performance optimizations in the btrees. It currently does linear scans on the keys in each btree node, when really it should be binary search. Doing some early profiling showed the number of keys comparisons is eating up CPU.

There are a number of big companies and small startups alike using CouchDB already. The uptake has been amazing here, I'm absolutely thrilled and CouchDB is being used to solve real problems. There is one company, a tech giant, that is piloting a couchdb project. If successful, CouchDB will be the storage engine in the next version of a product already used by millions.

But puzzlingly there is a lack of interest within IBM. I'm not much of an evangelist, but I thought people within Lotus would be interested. But so far, not so much.

Quick thought: Cloud computing is great. Right up until you lose your connection, then what?

Okay, that's 15 minutes. A quick read through, a few edits and a sick feeling at the lack of structure aaaaaaand publish.