Re: [RTF] AC019 proposal to WSA WG

Hi Mike,

On Tue, Jul 09, 2002 at 11:36:39PM -0400, Champion, Mike wrote:
> I've been trying to understand this position in a discussion with Paul
> Prescod on xml-dist-app.  I simply don't see why this is integral to REST --
> the basic read/write/update/delete operators on resource representations
> *could* be reliable, and perhaps *should* be in the WSA, even if HTTP as we
> know it is not.

There's a cost to making it reliable.  If it isn't required, as with
idempotent methods such as GET and PUT, then that's an enormous cost.
The cost is principally in reliable messaging solutions' insistance on
hiding the network from the developer, and the brittleness that ensues.
This (assumed transparency) has long been known to be a common mistake
of many distributed systems, as discussed in papers such as;

http://research.sun.com/techrep/1994/abstract-29.html

(see the bit about NFS)

>  It is clearly desireable to most web services developers to
> have the infrastructure guarantee reliable delivery (or notification of
> non-delivery) rather than leaving this responsibility to an application.

No, it is not.  See above.

> Insisting that reliable messaging infrastructures are somehow a bad thing
> seems to be making a virtue out of HTTP's well-known inadequacies as a
> reliable protocol.  "404's happen" might be good enough for the human
> centric web, but it's clearly a major annoyance for web services developers,
> hence a popular requirement for the WSA to define a solution to.

404s are extremely reliable.  They let you know, unequivocaly, that the
resource is not to be found.  The definition in RFC 2616 is quite
rigorous about what "not found" might mean.  Now, you probably meant
that you didn't want resources going away, and I'd agree with you that
it would be a good thing if they don't.  But that's not a technology
problem!  Sometimes things go away for all sorts of reasons.  At least
HTTP gives you options other than 404.  You've got 410 for when you
explicitly retire a Web service, 301 when the service moves
permanently, 302 when it moves temporarily, etc..

Are there other "well-known inadequacies" you had in mind?

Maybe you can answer me this; why is it important that HTTP GET or PUT
messages be reliably delivered?  I'll offer my answer; it isn't, because
in the context of a state transfer architecture, "reliability" means
ensuring that the client and server share a common view of the state of
the resource(s) (as required).  So if my PUT fails, or is indeterminate,
I can keep trying.  Ditto for GET.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Wednesday, 10 July 2002 00:24:15 UTC