XML-RPC and http

[Mark Baker]

Bill Hofmann wrote:
> Which is exactly the issue.  The side effects of an RPC call are not/may
> not be clearly defined.  But as others have pointed out, the side effects
> of HTTP POST vs GET are *implicit*, but not enforced by any kind of
> contract.  So someone looking at the HTTP stream might assume that a POST
> will have some stateful effect (a need to clean up the server room? ;->)
> and that a GET won't, but that assumption may not be correct.

You're right, that may not be correct.  The POST may not change the
state, and the GET might.

See section 9.1.1 of RFC 2616;

   Naturally, it is not possible to ensure that the server does not
   generate side-effects as a result of performing a GET request; in
   fact, some dynamic resources consider that a feature. The important
   distinction here is that the user did not request the side-effects,
   so therefore cannot be held accountable for them.

> So what you're really saying is that an administrator can't effectively
> manage an RPC connection (and really, any inbound HTTP connection) unless
> there's a clear, enforced interface contract that includes preconditions
> and especially postconditions.  IDLs (corba/com) don't make this explicit,
> and WSDL is not much better.  With HTTP, you're counting on the kindness
> (and understanding) of programmers to use GET and POST "correctly".

MB