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.
Ian Foster writes about OGSA-DAI (Data Access and Integration);
[…] it provides uniform Web Services interfaces to diverse data resources
Neat! That’s so 1990.
How many times do we really need to reinvent the Web, on top of the Web?
All this because of a little confusion over a word. Wow.
Peter Drayton posted the slides (PPT) from a presentation he gave at the WS DevCon. It’s very well done. Too bad I couldn’t have been there to hear it presented.