[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
>
>...
>
> I understand where Simon is coming from, but I'd like to hear a response to
> Paul from the mainstream folks who apparently believe that HTTP *is* going to
> work just fine for intrinsically stateful message exchanges using resources
> identified in the content of a POST rather than the URI. [Just to pull some
> apparent violations of REST out of some of the SOAP-RPC paradigm]. And from
> those who believe that the Internet is going to be sufficiently reliable for
> complex synchronous messaging Real Soon Now, even though [as Dan Gillmor points
> out in
> http://www.siliconvalley.com/mld/siliconvalley/business/columnists/dan_gillmor/
> ejournal/2649436.htm " The network connection [at Demo 2002] just failed.
> Incredible. If famous technology and telecom companies can't make it work for
> this crowd -- some top technologists and journalists -- do you believe it will
> ever work for regular folks?"
That's a rhetorical strategy that won't work. Whatever virtues we point
out of REST, RPC people will point out that you can do the same thing in
RPC if you just structure your method calls right. For instance you
could use a few verbs, as REST does. You could make them generic, as
REST does. You could always pass a URI as the first argument. You could
build client-side messages as XML documents and pass them through RPC as
content-bodies, as HTTP does. etc. You could reinvent it all in a new
syntax two levels above HTTP. And it would work.
.NET My Services is more or less like that, although it uses XPaths
instead of URIs which means that the namespaces are local rather than
global. (seems like a mistake to me...)
Paul Prescod
|
