Correcting MNot

Mmmmmm, bait...

If you really meant PUT, I agree with you on that point, although I must say that the SYSV runlevel example in the comments gives me pause. Do you consider that overloading?

WRT interface examples; just because specific interfaces makes sense in programming languages does not mean that they're good for distributed systems. I'm sure you're familiar with "A Note on Distributed Computing" (http://research.sun.com/techrep/1994/smli_tr-94-29.pdf), so I'm surprised to see you imply this.

Of course, that doesn't necessarily mean that uniform interfaces are better; just that arguing that they aren't desirable in programming languages isn't going to sway me much.

WRT Relax and SOAP - preaching to the choir. Tho I wonder if we'd get further with the RDF data model + RDF Schema (not the syntax, and not the higher levels of the semantic Web goo, at least yet). Of course, that's all moot now.

Mark,

For one, I'm not swayed by the runlevel example. You should talk to the directory folks who've had to deal with this sort of action-via-side-effect for years. They hate it.

And yes, I'm familiar with the Waldo piece and largely agree with it. Note that in my example, I'm going the opposite direction, that is, taking an abstraction that has been held up as a "good" distributed abstraction and am using that as a thought experiment for in-process software design.

And btw, I actually think uniform interfaces in "local" programming languages are huge - look at what we've done with IEnumerator in C# (especially with yield return).

And of course, you know how I feel about Relax and RDF :-)

DB

"it's sad (but not terminal) that SOAP's defun..."

defun?

OK.. answering my own question. Didn't realize defun is a Lisp-ism. For the uninitiated: http://www.gnu.org/software/emacs/emacs-lisp-intro/html_node/defun.html

Don, you wrote "It's a wonderful thought experiment, but trying to evangelize that the world only requires a fixed number of verbs is quite odd.". Not odd at all. It's how *all* Internet scale systems are built. Over the Internet, i.e. in multi-agency scenarios, integration is a coordination problem.

You can also look at this from a software architecture POV by simply examining the architectural properties induced by using a constrained interface. Things like visibility and simplicity. Without the constraint, you don't get those.

P.S. java.lang.Object already has Get() - it's called toString().

As usual in debates over RESTifarianism, things quickly go off into the trees over fairly minor points (PUT vs POST in a hypothetical RESTful "reboot my computer" interface) and miss the forest (whether it makes sense to actually build real systems this way even if it is logically possible).

Don writes "It's a wonderful thought experiment, but trying to evangelize that the world only requires a fixed number of verbs is quite odd. " I agree -- all the pushback has been that it is *possible* to do anything with basically the CRUD operations (especially if you have an open ended "doStuff()" operator such as HTTP POST. Who is arguing that this actually makes practical engineering sense in concrete large-scale, mission-critical systems?

Just about every system I had much design input into when I was a hands-on software developer started with something like a CRUD API, and quickly added higher-complexity operations. It would be enlightening to hear from people who resisted this temptation and kept it simple .... and kept their jobs :-)

This reminds me of the C.J. Date and friends argument that SQL sucks because it doesn't implement the relational calculus and only the relational calculus. He's right that is is provably the case that one could build databases the pure relational way, but almost nobody does for large-scale applications. Ignorance, or practical solutions to inevitable tradeoffs in any engineering endeavor?

As I may have suggested to Mark Baker, once or twice, over the last few years, SHOW US!!! The Web doesn't count as an examnple because it the main service it provides *is* exchanging representations of information for human consumption. When we get into areas where machine integration is needed, REST tends to go out the window -- try using an e-commerce site with cookies turned off, you'll either have a dreadful experience or the site will just tell you to turn on cookies or go annoy its competition :-) Or for that matter, Mark Nottingham's employer wouldn't do much of its bread-and-butter business if people followed REST prescriptions and didn't maintain server-side state except in identified resources. (Isn't keeping server-side state in a programmer-friendly manner what app servers do, in a nutshell?)

So, show us the real success stories for limited verb large-scaled automated systems that do something more that deliver information for human consumption. My guess is that engineering considerations such as performance / scalability tend to weed these out, even if they could work in principle.

Hey Mike,

Way to argue for complexity!

Seriously, I don't think that REST is the one true way, just that there's some value to identifying things that have state with universal identifiers. Please don't paint me as an extremist.

Don's previous post quoting Bill is on the money; the real lesson here is that both sides are far from perfect, and that they can learn from each other. Sorry if that isn't controversial enough.

Don,

Sorry for the delay in responding, it's been a bit of a week.

Would *love* to talk to your directory folks; can you set us up on a date? :)

Regarding Waldo; if you accept that treating remote interfaces as local ones doesn't work, I wonder why you're trying to treat local interfaces as remote ones; I think this is a false analogy.

I don't. To me, the keys are the three faces and WS-Get. Let's explore them in turn, Tim's first. One World My experience is that: WSDL can describe bindings of operations to many different protocols, but most bindings are to SOAP. SOAP can be tran

The discussion on the intersection between Web Services and REST continues, but a passing aside may hint at an equally imprtant issue for Web architecture.