Re: Few questions about REST

Hi Mark,

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

If I understand it correctly, a mandatory-intent header could explicitly say
that semantics of a given (POST) request are specialized, for ex, it could
indicate that a document in a POST request body will be echoed immediately
back, or will be sent separately by a server to a provided URL, etc.
The question is about intermediaries. It sees that it does not recognize a
given extension so it does not process this request as usual in line with
the semantics of the current method (POST, etc), but, perhaps, just forwards
this request to the next destination. Wouldn't it present some other
problems (security, etc)  ?

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

What is required for "SOAPAction" to support it and for external parties to
recognize that "SOAPAction" specifies such an extension ?

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

Thanks, some questions:

Am I right in assuming that a
http://www.intertwingly.net/wiki/pie/DifferentlyAbledClients proposal allows
for tunneling GET within POST while your proposal allows for using a pure
GET but also extending it by passing additional metadata, such as SOAP
headers ?

It seems to me now that it's not prohibited to pass some data in a GET body,
provided that those data do not indicate that a targeted resource be
modified. As you indicated, SOAP headers of idempotent nature could be
passed ok.
Please don't be shocked :-), by  why then it's wrong to pass GET parameters
in an envelope Body (provided that those parameters are just query
parameters) ? How much query parameters add to a visibility of a resource ?
I'm not sure but it seems that they're of use to a resource handler, but not
of much help to intermediaries.

I just don't understand what is the right way to tunnel GET within POST.
Such tunneling could be applied to uses of SOAP Http Binding, which requires
POST for all requests. The first step is to indicate the fact of tunneling
with SOAPAction, but what about the Body, will it have to turn itself into
POST parameters ?  Probably yes ...

Cheers
Sergey

Received on Thursday, 25 September 2003 17:58:57 UTC