« Javablogs trouble | Main | HTML elements with class attributes »

Web Idiocy (PUT, POST, J2ME, Atom, and reliable messaging)

Reciting chapter and verse of a 12 year old spec? I don't give a flying rats ass what that spec says. Russell Beattie

Back in the day, before we understood the value of standards that would've been the attitude I'd expect from, say, a large software company ;-)


Russell is rightly annoyed about all this, but he's rightly annoyed at the wrong things, the wrong people, and that's understandable given how we got here. I take the opposite view to Russ; not having mainstream availability of PUT and DELETE is the singularly most broken aspect of web technology today.

Let's go back. There is a broken spec in this story, but it's not Atom and and it's not HTTP. It's, wait for it... HTML. The reason technologies like SOAP and the Midp and Flash only use those verbs is because HTML only allowed POST and GET in forms. That's where the rot started.

What's the big deal? Well, the hoops you have to go through to do basic messaging on the web are frankly, ridiculous, and it results directly from inheriting the web forms legacy of abusing POST. For example, consider reliable messaging done over the web. The absence of client infrastructure that supports a full verb complement gives leeway to invent a raft of over-complicated non-interoperable reliable message specs. Reliable messaging, by the way, is one area that WS vendors can't seem to agree to standardize - perhaps that's because it's critical to enterprises (read, there's real money in it). But, the point is that there should never been an opportunity to make things complicated in the first place. In my job, we design and build messaging infrastructure, a lot of it happens over HTTP. There's a good amount of pressure to make that infrastructure fit with web forms technology and existing client stacks. Now, to do RM over the web, and do it cleanly, you want the full complement of HTTP verbs at your disposal (esp. PUT and DELETE). With them you can uniquely name each exchange and use the verbs to create a simple state machine or workflow operating over that exchange. Without them you have to use multiple resources to name one exchange plus clients and servers will typically have to inspect the URLs to find out what's going on. Operators and software have to be able to manage this, know all the URLs involved in the exchange, plus the private keys you're using to bind them together behind the firewall. Oh, did I mention that you'll have to reinvent these verbs in your content anyway and then get your partners to agree on their meaning? POST driven exchanges become to a small degree non-scalable, to some degree insecure, and to a large degree hard to manage.

Trust me, it's not an academic issue, and it's not limited to RM; basic content management is in scope too. For those of you that don't monkey about with HTTP for a living, I can sum up the problem of the problem of not having PUT and DELETE like this - imagine dealing with a subset of SQL that doesn't suppport UPDATE and DELETE or Java Collections that didn't have an add() method. It's an insanely stupid way of working. But if you never knew SQL had UPDATE to begin with, and it was useful, perhaps that wouldn't be as apparent.

The irony is, that while some of us are left to compromizing with the fallout from uninformed specs, a number of people think that PUT and DELETE are some sort of esoterica that only a spec wonk could care about. And now, over on the Atom list some people are talking about workarounds. To heck with that. Get Sun to fix the Midp and the W3C TAG to fix HTML/XForms. The latter is worth emphasizing - as far as I can tell, this issue isn't even on the TAG's radar.

Russ, sorry; Atom is not the broken spec and the REST folks are not being intransigent nerds (this time). Argung for a subset of HTTP is not the way to go here, even if it's the expedient way right now for J2ME. Sure there are hundreds of millions of broken clients out there, but what worries me are the next billion clients, not the early adopters.

February 21, 2004 02:11 PM


Randy Charles Morin
(February 24, 2004 07:17 AM #)

Great, but everybody knew this going in and now we are six months down a dead-end path. If AtomAPI had gone the path of SOAP instead of REST, then we'd be all swimming in Atom applications and not arguing about who is wrong.

Trackback Pings

TrackBack URL for this entry: