W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

Re: Getting no REST

From: Mark Baker <distobj@acm.org>
Date: Tue, 5 Mar 2002 13:32:59 -0500 (EST)
Message-Id: <200203051832.NAA03294@markbaker.ca>
To: skw@hplb.hpl.hp.com (Williams, Stuart)
Cc: xml-dist-app@w3.org
Stuart.  This discussion is blossoming.  If you don't mind, for the
moment I'd just like to focus on a couple of points.  If you ask, I
will respond to the other parts of your message.

> > Ah, see, there's the rub.  Application protocols *already* define those
> > semantics for you (some being more general than others).  The chameleon
> > view reuses them, whereas the tunneling view ignores them and reinvents
> > new ones.
> 
> I don't think I've seen anything in HTTP that attributes any semantics to a
> particular resource or resource representation.

That's what the HTTP method does; "PUT <resume>" means something different
than "POST <resume>", for example.

Consider a calendar.  PUTting a calendar replaces the old calendar with
the new calendar.  POSTing a calendar could be interpreted as trying
to arrange a meeting represented in the posted calendar, to my calendar
as the resource being posted to.

> A well specified sequence of
> resource manipulations intended to achieve some effect (place books in a
> shopping cart and pass through a checkout) is itself an application
> protocol.

Right.  But any task can be modelled as resources interacting via
insertion (POST), replacement (PUT), retrieval (GET), and deletion
(DELETE).  SQL (INSERT, UPDATE, SELECT, DELETE) works this way.
Unix (<, >, >>) works this way.  So why have methods "addBook()",
"getBook()", when "POST <book>", and "GET /book" would suffice?

By generalizing distributed containment based operations, we create an
enormous opportunity for optimizing and securing our systems.
Optimization, because rather than requiring different intermediaries to
optimize book sales and dvd sales, we permit a single intermediary to
optimize both.  Ditto for security; we can have a single firewall that
permits us to define a security policy around generic methods, rather
than individual firewalls for each of DVD and book purchasing.

> > That's what a SOAP HTTP/SMTP gateway would do.  The value of SOAP as a
> > protocol here is the extended end-to-end model; that I could include
> > extension headers that I require that your end understand (assuming
> > your receiving SMTP processor dispatches on one of the headers we
> > included - note to self, see what email binding does here).
> 
> So... in this example, what goes in the HTTP POST response? How long does
> the gateway wait to decide?

That depends what we're trying to build.  For "just email", I'd return
a 200, since the gateway's job was successful - it got the message to
the MTA ok.

> What happens if the email system spits out a delivery failure message eg.
> been trying to deliver for 3 days and will keep going for another 8 days?

Then I would receive a notice because my email message is in that
message.

Alternately, if we wanted to build something with better end-to-end
guarantees I'd return a 201, create a resource in the gateway that
could be used to track the message, and return the URI of that resource
in the body of the 201 response (even a SOAP fault).  Then the client could
invoke GET on that to track it, much like you do with UPS.

> Ok.... there are four cases and I focussed on the wrong case (FIM=fault in
> message; FRP=Fault reported by underlying protocol):
> 
> 	FIM	FRP
> 	0	0	Clearly no fault!
> 	0	1	In consistency=>non-conformant message creator.
> 	1	1	Clearly a fault!
> 	1	0	see below.
> 
> Personnally, I think I would prefer the quotedness of the fault to be
> apparent within the message itself in which case I would regard this last
> case as non-conformant ie. if there is an unquoted fault in the message, its
> a fault and if the fault is quoted (wrapped) then overall the message is not
> a fault.
> 
> I suspect that your preference would be to make the FRP authorative, as a
> means to quote faults rather than assert them.

Right.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com
Received on Tuesday, 5 March 2002 14:41:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT