Re: Few questions about REST

Mark,

> Right, but the client didn't request that response.  It was just a result
> of processing the data that was submitted.  Intermediaries wouldn't be
> confused.
>
> With "echo", the response is explicitly requested.  Intermediaries would
> be confused.
It's clear enough now, thanks.

> > How POST in this example can be used RESTfully to
> > see what happens after the data has been submitted ?

> Well, you just POST the data, and see what you get back.  If it's a 201,
> then you know a new resource was created in response to your POSTed
> data, and you can invoke GET on that.  The POST response might also just
> contain a link someplace else, which you can invoke GET on.
Ok, as far as a (generic) intermediary is concerned, how the response could
be usefully handled before it's passed to an immediate requestor ?
Probably, if it's 201, then a newly created resource could be fetched in
advance so that it's already available by the time a request from an
(original) client arrives, and this also would require that intermediary
sets an URI of a newly created resource to its own one ?
What if it's not 201, but some data, as in a response from a primer, where
clarification request is returned after processing an initial booking
request ? An intermediary can not predict that a clarification request will
be or won't be returned in a POST response ; if it's returned, then how it
can be generically processed?

I'd like also to ask about late-binding and a tool support. With WSDL R085,
a tool can generate a set of classes for a client. It seems that
late-binding assumes that no code generation is needed, because a generated
code  early-binds a client. What is a programmimg model for accessing
late-bound services ?
If a client wants to get a quote from a late-bound, SOAP-based service , it
could ask for it like this :
POST soapgateway;stockquote:sunw
and from another non-SOAP service like this :
GET quotes/sunw,
using the same code, perhaps normalizing response data into a common format.
So a question is : can a code be generated for a client so that it could
transparently talk to multiple services ?


Thanks
Sergey Beryozkin








----- Original Message -----
From: "Mark Baker" <distobj@acm.org>
To: "Sergey Beryozkin" <sberyozkin@zandar.com>
Cc: <www-archive@w3.org>
Sent: Friday, September 19, 2003 1:05 AM
Subject: Re: Few questions about REST


> On Thu, Sep 18, 2003 at 06:17:57PM -0400, Sergey Beryozkin wrote:
> > Mark,
> > > > Almost, but not quite 8-).  What you're missing is that POST - even
when
> > > > extended as you describe - cannot RESTfully be used to have any
insight
> > > > into what happens after the data has been submitted.  "echo"
semantics
> > > > are such that there exists an expectation that what is submitted, is
> > > > returned.  It's that expectation which is not RESTful.
> > I have to admit I'm somewhat confused. It seems to me that "echo"
semantics
> > are only 'visible' to a client and a service
> > A generic intermediary would probably be confused because it's not aware
of
> > the semantics.
>
> That's exactly right, and a good litmus test; if the intermediary is
> confused, then it's not RESTful.
>
> > Is it more RESTful to POST Person details first and then GET it back or
ask
> > a service to POST it to a provided URI, instead of combining it into a
> > single POST ?
>
> The former, since the latter requires asking the service to do something,
> which you can't do RESTfully with POST (except to POST, of course 8-).
>
> > I think that those uses of doc-lit SOAP which actually do RPC can be
> > considered unRESTful (empty input bodies, or perhaps with some
structures
> > clearly representing parameters, many fine-grained invocations, etc)
> >
> > > > Here's one that I think is RESTful;
> > > >
> > > > http://www.w3.org/TR/soap12-part0/#Example
> >
> > This is why I'm confused. This example seems to be very similar as the
one
> > with echoPerson.
> > That example shows an input message, which is followed by a response
asking
> > for some clarifications.
>
> Right, but the client didn't request that response.  It was just a result
> of processing the data that was submitted.  Intermediaries wouldn't be
> confused.
>
> With "echo", the response is explicitly requested.  Intermediaries would
> be confused.
>
> > How POST in this example can be used RESTfully to
> > see what happens after the data has been submitted ?
>
> Well, you just POST the data, and see what you get back.  If it's a 201,
> then you know a new resource was created in response to your POSTed
> data, and you can invoke GET on that.  The POST response might also just
> contain a link someplace else, which you can invoke GET on.
>
> Mark.
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>
>

Received on Friday, 19 September 2003 04:58:47 UTC