Ramin Firoozye wrote:
>
>...
>
> Actually, this is endemic to ANY mechanism that invokes code and is
> fronted by an HTTP GET -- not just Didier's SOAP redirector.
Dideier's SOAP redirector doesn't have anything to do with HTTP GET!
> He could just as easily be calling a servlet that issues JDBC calls
> to update hit counters. Calling it a server bug isn't going to fix the
> issue (if it's even broken).
In the end, we only use standards for two things: to try and work
together and to ascribe blame when that fails. The XML specification
does not force Netscape to use less-than signs rather than parens.
Rather, it is human beings applying moral pressure that forces them to
do so (using the XML specification as backup).
>...
> By the way, the entire ad-driven web-site industry practically depends
> on a side-effect of GET -- namely modifying the log entries so it can be
> counted.
The HTTP specification says that this is perfectly legal and even
acceptable. It does not say that GET will be side-effect-free. It says
that the client has no responsibility to care one way or the other about
the side effects.
> ... If one steps away from the canonical purity argument, I'm not sure
> the GET vs. POST thing is worth losing much sleep over.
It matters for the reason any other standard matters. To enable
interoperability.
> > Another thing is that many SOAP advocates say that most real-world SOAP
> > services will NOT use the SOAP RPC conventions. This means that your URL
> > construct will not work with them.
> >
> > Paul Prescod
> >
>
> Hmm, could you elaborate on the last paragraph. I haven't heard anyone
> mention anything about the short lifespan of SOAP/RPC...
I didn't say that SOAP-RPC has a short lifespan. I said that SOAP RPC is
widely acknowledged to not be the model for scalable, extensible,
multi-organization web services. Just for you I've collected some
evidence to this effect:
* http://www.prescod.net/soap/views/
Nevertheless it is kind of common sense if you think about it. Web
services are supposed to be "loosely bound". How can you be "loosely
bound" if you are deeply dependent on the exact number, order and type
of parameters to a method call.
Paul Prescod
