XML-RPC and http

[Roy T. Fielding]

> Hmm. I expect a protocol spec, first and foremost, to 
> describe the protocol, and to specify what correct
> implementations of it must do, and may do, from both
> sides. This should be a technical description that is
> expressed with some degree of mathematical rigor. 
> How's *that* for a best practice?

It does that to the degree that is possible for an interface that
makes absolutely no assumptions about implementation behind the interface.

> > .. if I hired you to build a Web site according to those 
> > best practices, and you abused HTTP semantics ..
> 
> I didn't understand this whole business about abusing
> protocols when it was discussed a few weeks ago, 
> and it seems just as mysterious now. Either an 
> implementation satisfies a protocol, or it doesn't. The

It is possible to obey the syntax of a protocol without obeying the semantics
of a protocol, and hence you can abuse the semantics by exchanging a message
that claims to be doing one thing and yet expects the implementation to do
something else based on some external understanding of the implementation
behind the interface.

> problem with some of the notions expressed here is
> that they are so fuzzy that it is impossible to tell 
> what satisfies it and what doesn't. Let's see ..

If it abuses the semantics it does not satisfy the protocol, obviouly.

> GET 
> is supposed to be "idempotent," and is not supposed 
> to "cause" stateful changes to websites. Does the 
> spec explain these notions with some rigor?

Yes, it does to the extent that is meaningful for the interface.

> Does
> a page counter violate the second? Does a website
> that changes it display according to the number of
> recent visitors violate both? Is the spec adequately
> precise to definitively answer these questions, and
> others about what implementations of GET would
> violate these requirements? For example, can you 
> write a test program that identifies when a site 
> fulfills these requirements, and when it fails these 
> requirements? 

Have you missed the difference between a resource and a representation
of a resource?  The method is an action on the resource.  Idempotence
of methods is specifically not identical to idempotence of mathematical
operations, as is explained in the spec.  We did not attempt to make it
more formal because the goal was to have the specification describe the
interface as it was intended, not define it in such a way that only
static resources could be implemented.  There is no known mathematical
definition for this because the client cannot know the exact nature of
the semantics of a resource, and it is precisely because it cannot know
the nature of a resource that the Web can be used as an interface for
so many different things as resources.

....Roy