According to Steve Jones, REST is a career limiting move;

But as with any technical discuss there is another thing that should drive you when you look to your decisions. This is whether you want to get fired for a decision when something goes wrong, and whether you want your skills to be relevant in 3 years time.

That would be funny if it weren’t so sad; completely accurate, yet aimed entirely in the wrong direction 8-(

Danny notes that I chimed in with some Web architectural advice for those considering SPARQL updates.

On that page, he asks;

I’d like to hear more from Mark about what he sees as problematic about the current notion of binding. Although the spec seems unusual, the end result does seem to respect WebArch

It does respect Web architecture, but only because it’s read-only. As soon as you need to add mutation support, or indeed any other operation on the same resource, the process fails and what results is not Web-friendly. This is because “operation on the same resource” doesn’t work if the operation is part of the resource name; if the operation changes, the name changes, and therefore the resource-identified changes.

This is the same problem that APIs such as Flickr and del.icio.us suffer from; Web-friendly for read-only, horribly broken for updates.

Making something Web-friendly means mapping your data and services into a set of inter-linked resources. Application-specific APIs works directly against that.

And FWIW, from a REST POV the constraint that’s being disregarded in these scenarios is commonly resource identification.

  • “with REST, this turns out to be easy to fix”. I have to disagree that this is a quality of REST. One could easily build that capability into specs looking a whole lot like SOAP/WS-*, but you’d still have a crappy architecture.

Sanjiva gave a talk at Google on Web services, which also touched on REST. Unfortunately there’s a lot of misinformation in there about REST, including a statement to the effect of “If you want to sign your message, you can’t use REST” (I don’t think I’m taking that out of context), plus a slide (@ 25:00) that includes the following;

REST vs. WS-* is the wrong battle
- WS-* is used to create Service Oriented Architecture
- REST is used to create Resource Oriented Architecture

When taken together with some other comments, it appears as though Sanjiva sees REST as an alias for HTTP (or perhaps HTTP/URI), which it isn’t of course. He’s certainly entitled to his own beliefs, but I think he would do well to spend a couple of days with his nose buried deep in Roy’s dissertation… and not just chapter 5. Until that happens, I’d personally avoid trying to make conclusions about how these different approaches may or may not relate, or may or may not compete.