RE: Getting no REST

Hi Mark,

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: 05 March 2002 18:33
> To: skw@hplb.hpl.hp.com
> Cc: xml-dist-app@w3.org
> Subject: Re: Getting no REST
> 
> 
> 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.

That's fine... some brief replies below.

> > > 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.

No... HTTP attributes semantics to the action "PUT" or "POST". It attributes
no semantics whatsoever to the resource representation <resume> - we don't
know what it is or what it represents, we don't know what effect of POSTing
it will be, only that there may be some (side) effect.

As it happens I don't think that HTTP should tell us about the significance
of individual resources either (you'll be relieved, that could be a very
long task ;-) ). What I am trying to show is that HTTP is just one part of
the agreement. The significance of the resources, the syntax of their
representations, the semantics associated with (possibly sequenced)
manipulations of resource state are also part of the agreement.

> > 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?

I'm not arguing for more HTTP methods or for application specific methods
(cf RPC)... I'm only arguing that there is more to the agreement than HTTP. 

> 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.

On optimisation, certainly the semantics of GET properly used have
considerably helped the Web scale and help reduce use perceived latencies...
no disagreement.

On security, well yes, but down at the http generic method level in a
firewall box, then it's pretty coarse grain. We might want different
policies in force around with respect to different resources and the
firewall has to be configured with a greater awareness of the resources that
lie behind the firewall.

> > > 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.

So I think I'd do something more like the latter. The point of the question
really was to say that there is more to it than simply mapping the message
content from an HTTP request body into an email message.

> MB
> -- 
> Mark Baker, Chief Science Officer, Planetfred, Inc.
> Ottawa, Ontario, CANADA.      mbaker@planetfred.com
> http://www.markbaker.ca   http://www.planetfred.com

Regards

Stuart

Received on Wednesday, 6 March 2002 04:19:40 UTC