Re: Few questions about REST

On Thu, Sep 25, 2003 at 08:16:41AM -0400, Sergey Beryozkin wrote:
> Hi Mark,
> 
> > > Do you mean something like
> > > http://www.intertwingly.net/wiki/pie/DifferentlyAbledClients ?
> > > As far as doc-lit SOAP is concerned, this approach can make those
> doc-lit
> > > SOAP requests which use POST but mean GET RESTful enough, at least
> > > technically.
> > >
> > > Do you agree ?
> >
> > Almost exactly.  I made some comments on that Wiki page to Sam last
> > week;
> >
> > http://groups.yahoo.com/group/rest-discuss/message/3978
> 
> Can you please send me a link to a correspondig WebServices Activity thread
> you refer to in those comments ?

http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/thread.html#416

> I'd like to return to an echoDocument example.
> The best way (from the REST perspective) to echo a document is to decompose
> a single POST operation into two operations, one is POST, another is GET
> which will fetch an original document using a URL provided in a POST
> response.

I wouldn't say that.  That's certainly one way, but probably not the
"best" in that it's inefficient.  There's another way.

> Would it be possible, using the above tunneling approach, to echoDocument
> using a single POST in a RESTful manner

Yes.

> ? For example, one may specify that
> the semantics of this POST request are those of GET (using (SOAP)action
> attribute), thus presenting a document to be echoed as GET parameters ? This
> approach will not be purely RESTful, but it seems that the advantage is it's
> only 2 network trips instead of 4 ones with POST and separate GET.
> Can some extra efficiency associated with a single (more or less techically
> RESTful) POST outweigh the benefits offered by a pure REST approach (POST
> and GET to echo document) ?

No, that's pretty unRESTful ...

> Another question is about POSTing a document and providing a URL where a
> document has to be returned. You said it's unRESTful, presumably because the
> action of a server sending a document does not meet POST expectations. The
> advantage of this approach, though, is that it allows a client to POST a
> document, get HTTP 200OK with empty content and forget about it for some
> time, later on, a server would sent a document back to a client. Would it be
> RESTful to do it this way ?
> A client should probably to a server that a document should not be sent to a
> provided URL while a response to this POST is pending, that is a server
> should just return 200OK and send a doc using a separate POST

While REST requires uniform connector semantics, it doesn't prevent
those semantics from being specialized, so long as --- key point
here --- any expectation of specialized semantics is indicated as part
of the message in a self-descriptive manner.  Consider that when I was
talking about "confused intermediaries", that an intermediary would not
be confused if it knew that an extension was in use that it didn't
understand.  Given that, "echo" might best be done like this;

POST http://some-host/some-uri HTTP/1.1
Mandatory-Intent: http://example.org/standard-resource-types/echoer
[body goes here]

There, I would have used "SOAPAction", except that SOAPAction doesn't
support a mandatory strength declaration; i.e. it can't say "this
extension is critical to understanding the semantics of this message".
SOAP 1.1 and 1.2 don't have that capability, which I consider a bug.
But that's the basic idea.

I probably should have mentioned this before, but I thought it might
have been too much to try to explain up front.

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

Received on Thursday, 25 September 2003 09:17:41 UTC