W3C home > Mailing lists > Public > www-archive@w3.org > September 2003

Re: Few questions about REST

From: Mark Baker <distobj@acm.org>
Date: Fri, 12 Sep 2003 19:50:11 -0400
To: Sergey Beryozkin <sberyozkin@zandar.com>
Cc: www-archive@w3.org
Message-ID: <20030912195011.G4344@www.markbaker.ca>

On Fri, Sep 12, 2003 at 05:43:58PM -0400, Sergey Beryozkin wrote:
> > To me "doc-style SOAP" is "RESTful SOAP".
> OK, it feels to me it is indeed, I just need to correlate what you explained
> to me with this statement.  Most probably I'm missing something, but to me
> it means that to be RESTful doesn't mean that all REST constraints should be
> (strictly) met.

Well, technically it does.  REST is pretty strict, because it requires
that certain constraints be followed.  If you don't follow all of them,
then you're not RESTful, though you may be "mostly RESTful", or "nearly
RESTful".  But some constraints are more important than others in
determining how "mostly" or "nearly" you are.

> I may be wrong but this is what I think at the moment :
> First of all, it seems that doc-style SOAP does not (strictly meet) a
> resource identification constraint, because even though pure docs are
> exchanged (no method names), it's not possible to find a mapping to
> representation from a resource identifier alone, which is normally found
> today by combining a URI and a control parameter (I meant SOAPAction header
> or an action attribute of application/xml+soap mime type), which is not a
> part of URI.

Yes, well said.

> That's why I was asking whether such a combination would meet the
> constraint, and you think it would not.


> But if something like http://example.org/soapGateway;stockquote:sunw is
> semantically equivalent to
> http://example.org/soapGateway
> application/xml+soap; action : stockquote:sunw
> (sorry, I'm not sure about the syntaxis )
> then doc-style SOAP does meet this constraint

If you're saying that if doc-style SOAP used the URI there, then yes.
That's RESTful SOAP (at least for those subset of REST's constraints
that we're discussing).

> Because late-binding is derived from a combination of a uniform interface
> and resource identification constraints, doc-lit SOAP is early bound, also,
> a generic firewall might also have problems as all requests, while being
> pure docs, are still sent to a single URI (if my argument that it does not
> meet a latter constraint is correct)

Yes, that's true too.  Putting identifying information in a place where
the firewall doesn't know to look, is reducing visibility in a similar
way as moving the method around the message envelope does.

> Second, a doc-lit SOAP does not always meet a uniform interface constraint
> (which assumes that every method has well-known semantics) when it uses POST
> for information retrieval operations. One can use a Web Feature method, that
> is to use GET for a retrieval, but this seems to be used only as a
> bootstrapping operation invoked only once as a very first operation.

You mean for the WSDL?  That's what I've seen the Web method feature
used for more than anything else.  Though it's pretty early to say that
a standard practice with it has emerged.

> Subsequent retrievals will still be POSTed for (I'm not completely sure I'm
> correct here), which means generic intermidiaries can't cache the response,

Right.  Amoungst other things ...

> because they don't expect anything more than HTTP 200 OK from such a
> request.

I wouldn't say that.  They can't cache it because it's not using GET

> I'd appreciate your comments on this.
> > telnet example.org 8080
> > GET stockquote:sunw HTTP/1.1
> That's neat, I didn't know about this technique, thanks

Sure.  That's the magic of the uniform semantics of HTTP; they apply to
all resources, not just those using the http scheme.

> Cheers
> Sergey Beryozkin
> P.S. Sorry for reordering your comments from the last reply

I didn't even notice! 8-)

Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Received on Friday, 12 September 2003 19:46:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:42:31 UTC