Patterns of Change

Reg Braithwaite knows...

Of course I recommend reading the original. But may I add, please do not get sucked into arguing whether Design Patterns are good, or whether IDE refactorings really work, or any of the other technical points that are so much fun to rehash for the millionth time.

Instead, consider the cultural forces at work. Cultural problems cannot be solved with technology. If you are an advocate for change, ask yourself what sort of cultural change is needed, not what sort of technical problems need to be solved.

RubyCamp 2008 in Vancouver

This announcement came around...

RubyCamp 2008 in Vancouver on Saturday, January 26th.

RubyCamp is an one-day gathering for Rubyists and Railers.

When and Where:

WorkSpace in downtown Vancouver, B.C., Canada
January 26th, 2008 from 9:00 to 5:00

We've been getting into the JRuby here, and a couple days in Vancouver might be nice. This may go on the list of game-time decisions.

Where's the Beef?

Subbu Allamaraju shows that a significantly more RESTful api than Amazon's SimpleDB is not so difficult to conceive.

The SimpleDB API is neither resource oriented nor HTTP friendly. Having said that, how should such an API be designed in a resource-oriented manner? Here is my take, a version-0.1 of a RESTful SimpleDB. In the design below, I tried to keep the semantics of this version as close as possible to the official SimpleDB API

The Wayback Machine: Internet Archive

James Robertson and Robert Scoble lament the loss of one's data one old sites they themselves do not own. But the Internet Archive's Wayback Machine does a reasonable job of rescuing this. (Could wayback rescue your facebook if that were to disappear?)

e.g. my old Radio Weblog is no longer around: http://radio.weblogs.com/0100812/

However the Wayback Machine can find it: http://web.archive.org/web/*/http://radio.weblogs.com/0100812/

Note that the wayback machine continues to archive the "not found" page. Actually whatever service is running the old Radio is returning a 300, "multiple choices", rather than a 404, "not found".

So using the archive you can actually see when my Radio went off the air, sometime between December 7, 2003 and April 5, 2004.

It looks like the archive has not been able to retrieve at least all the longer essays, which Radio stored under a "story" URL.

Also without exhaustively searching the archive, the earliest criticism of WS-* that I have found of mine is August 25, 2002. See "Protocols, Documents, and Transactions"

Thud

How did Amazon allow this design out into the wild? Apparently they've already had a private beta period with non-Amazon developers. No one suspected this use of HTTP GET to be a poor choice?

It's 2007. There are all kinds of basic REST reference and getting started materials. Didn't the whole net go through that "Google is pre-caching everything it can GET" episode a couple years ago. That's the episode where the Rails folks learned that GET should not have side effects.

Wow. Hopefully Amazon will POST a fix asap.

Subbu Allamaraju calls this "SOAPy REST". Didn't even the SOAP folks learn to avoid these kinds of GETs a couple years ago?

IBM published an article recently on using HTTP to access DB2 and IDS. The URLs they provide need improvement, embedding the operation in the URL. This despite that they do seem to be distinguishing between GET and POST. From the information at that site and another bit I could get behind their developerWorks login, it's not clear to me yet whether they allow the use of GET with a URL that includes a destructive operation.

Maybe the RESTful Web Services book will begin to turn these things around. But that Amazon did this in 2007 is a bit of a shock.

Update: Steve Loughran nominates SimpleDB for a new award...

I nominate it for the 2007 Restless awards, in the much contested category of

"things that claim to be RESTful but do side effects in their GETs" along with the ever popular "SOAP endpoint in disguise" category

I know this mailing list has not, historically, had such awards, but now is as good a time to start as any.

Yeah, maybe there should be annual (or more frequently, on Internet-time, awards for "RESTless" and "RESTful" web services that degrade or enhance, RESTpectfully, the web.