RE: [RTF] AC019 proposal to WSA WG

I honestly do not understand this discussion.  Is there some fundamental
disconnect here?  If so, what would get people talking about the same
issues?

I sort of thought that the requirements for web services, and thus the
architecture, are supposed to be driven by usage cases and scenarios.   It
seems to me that there are numerous usage cases and scenarios that
illustrate the importance of reliable messaging mechanisms that are widely
agreed upon so that one may expect all the parties of a transaction to deal
with this messaging issue in a compatible and mutually understood manner. I
personally think that this requirement is EXTREMELY important, right up
there with the security issues.  I don't see how web services can
successfully be used in realistic business situations without well
understood and agreed upon solutions in both areas.

Frankly, if the best the REST approach can do is say that the application
programmer can deal with 404's, I don't really have a lot of desire to hear
much of anything else about REST.  But surely that is not where this
discussion has to be, is it?  Is there some way of restating, or possibly
understanding in a different way, the legitimate concerns on both sides of
the controversy in such a way that they are not so mutually incompatible?

-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org] 
Sent: Tuesday, July 09, 2002 11:36 PM
To: Champion, Mike
Cc: www-ws-arch@w3.org
Subject: 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 01:14:25 UTC