> I don't see any reason why SOAP can't support dynamically changing sets of procedure calls. Furthermore, I think that is a bad idea since it will break backward compatibility. No amount of web-buzzwording will get around that problem.

Of course enclosing a message in a SOAP envelope does not preclude RESTfulness. If the set of messages to which an object responds is a function of its current state then it's RESTful (or at least lead to a RESTful design).

So what you're admitting is that REST doesn't add any new novelties in terms of being discoverable?

REST doesn't offer new novelties because the basic idea is at least as old as Smalltalk.

REST isn't even about discoverability. That's just a natural consequence of calling methods that might only exists when an object is in a particular state (i.e. the object creates the methods at runtime).

The difference between REST and (usual) SOAP is the difference between late-binding and "extreme late-binding"[1]

[1] http://www.google.com/#sclient=psy-ab&hl=en&source=h...

I didn't mean to say that (but I guess it looks like I did). Obviously there are other ways if singnalling receipt of a bad message (throwing exceptions for instance). METHOD_MISSING seems more natural to me at least.

What I meant to say is that in REST, the set of messages to which an object will respond is a function of the object's current state. With SOAP, a URL endpoint always takes the same set of messages (until the code is rewritten or something).

I don't see any reason why SOAP can't support dynamically changing sets of procedure calls. Furthermore, I think that is a bad idea since it will break backward compatibility. No amount of web-buzzwording will get around that problem.