Re: Few questions about REST

Mark,
Thanks,
I think I understand pretty much everything (fingers crossed :-)) you're
saying about issues associated with messages containing method names. What I
am and was really interested about is in trying to see how RESTful doc-lit
SOAP-based services are, and understand what it really means to be RESTful

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

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)

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.
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,
because they don't expect anything more than HTTP 200 OK from such a
request.

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

Cheers
Sergey Beryozkin

P.S. Sorry for reordering your comments from the last reply

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


> On Fri, Sep 12, 2003 at 12:56:54PM -0400, Sergey Beryozkin wrote:
> > Hello Mark,
> >
> > Thank you for answering the questions.
> > More questions on the way :-)
>
> No prob!
>
> > > > 1. You're saying that SOAP-based services are early bound.
> > >
> > > Well, first off, let's be clear that not all SOAP based services are.
> > > SOAP can be used RESTfully, or in other late-bound ways.  Can we say
> > > that "SOA based services" are early bound?
> >
> > Do you refer to the fact that in general it's typical for a client to
obtain
> > a service definition first, generate proxies with the type information
(at
> > compile or run time) and only then start accessing a service using a
single
> > (URL) identifier which is not sufficient to identify an interface of a
> > resource targeted by a current request ?
>
> Pretty much, yes.
>
> > How important is it for a server to follow a late-binding model ? Is it
> > mainly about load-balancing and hot deployment ?
>
> Not mainly IMO, no.
>
> > One possible disadvantage
> > is that it may cause a slower initial processing time ...
>
> Right.
>
> The main advantage is improved visibility, and reduced coordination
> costs as a result.  Integration is fundamentally easier in this approach,
> as integration complexity is not necessarily O(N^2) like with Web
> services.  i.e. if you have N services you want to integrate with, you
> don't necessarily need to write N pieces of code.
>
> > > Hmm, well, for "early bound", I just mean that handles (identifiers)
are
> > not
> > > sufficient to help you know the interface of the thing that the handle
> > > identifies.
> > >
> > > So a late bound version of the getStockQuote service would use
identifiers
> > > such as;
> > >
> > >   stockquote:sunw
> > Is it essential for a 'stockquote:sunw' be part of a resource URI or can
it
> > be submitted as a control parameter ?
>
> I was suggesting that it be the URI, not just part of it.
>
> > A resource identifier would still be
> > opaque, but when combined with that control parameter it would allow for
a
> > late binding to happen.
> > For example, a SOAP-based, document-style service will not have any
method
> > names in a message body, but rather use a URL and optionally a control
param
> > or some token within a message body to find a handler, possibly using a
> > late-binding model
>
> Well, if the "control param" is either all or part of an identifier,
> then it belongs in the URI.  But if you mean something like;
>
> http://example.org/soapGateway;stockquote:sunw
>
> then sure, that's a great way to have th WSDL-described getStockQuote
> interface implicit in the "stockquote" URI scheme, engulfed by the
> http URI scheme.  Another way would be an HTTP proxy;
>
> telnet example.org 8080
> GET stockquote:sunw HTTP/1.1
> etc..
>
> > > As REST relates to binding, the combination of the two interface
> > > constraints, "uniform interface", and "identification of resources"
> > > combine to require late binding, I believe.
> >
> > Would a URI + control parameter (media type's parameter, etc )
combination
> > meet a "identification of resources" constraint ?
>
> As long as they're just data, yes.  i.e. no methods allowed.
>
> > > > 2. HTTP verbs (POST, GET, etc) :  do they meet a uniform interface
> > > > constraint ?
> > >
> > > Yes.
> >
> > > > So, SOAP, by using POST where GET is more appropriate, violates this
> > > > constarint ?
> > >
> > > Well, the uniform interface constraint is violated by SOAs not
normally
> > > because POST is used, but because it changes the semantics of a
> > > successful response.  A RESTful/uniform use of POST requires that
> > > success mean little more than "Ok, got it".  By putting another method
> > > in the POST body, and making that part of the interface, successful
> > > response semantics mean that the method has executed.  That's more
> > > information than a client would have in the RESTful use of POST.
> >
> > I thought that the major problem with overusing POST was that upstream
> > generic processors could not cache info which is GETable by its nature.
I'm
> > not seeing yet what are other side effects when a POSTed request will
return
> > HTTP 200 OK plus some additional data in the body, can you please
explain
> > more.
>
> It's not the additional data that's the problem, it's the extended
> meaning of "200".
>
> Say you're a firewall, set up to monitor interaction between me and
> some piece of software you're responsible for.  Say you see a message;
>
> POST your-uri HTTP/1.1
> Content-Type: text/plain
> Hello
>
> And a successful response;
>
> HTTP/1.1 200 Ok
>
> Who knows what?
>
> The client knows the server accepted a text document.
> You know the server accepted a text document.
>
> Now say you do RPC over HTTP as text;
>
> POST your-uri HTTP/1.1
> Content-Type: text/plain
> getStockQuote("SUNW");
>
> And a successful response;
>
> HTTP/1.1 200 Ok
> Content-Type: text/plain
> 22.22
>
> Who knows what in this case?
>
> The client knows the server returned the current value of SUNW
> You know the server accepted a text document.
>
> So the general issue is that intermediaries are left out of the loop.
> Best case, that means caching doesn't happen.  Worst case, that means
> that you're no longer protected by your firewall, and that you're
> depending upon there being no security flaws in the RPC interface that
> has now been exposed to the world.
>
> > > > It can result, for ex, in intermediaries being unaware that a
> > > > responce can be cached ? What are other side-effects ?
> > >
> > > Security problems, as the firewall can no longer follow what's going
> > > on over it.
> > It's probably mainly to do with the fact that resources are not
identified
> > with unique URLs ?
>
> Not really.  See above.
>
> > If so, then even doc-style SOAP-based services present an issue for
> > non-specialized firewalls...
>
> If there's a method in the envelope, then yes.
>
> > > Evolvability and durability problems, as the message is more prone to
> > > losing its meaning over time, as the embedded semantic indicated by
> > > the tunneled method is not grounded in public specification or the Web
> > > itself.
> > These seem to be the major problems with tunneling (SOAP-RPC), but they
> > don't apply to doc-style SOAP, do they ?
>
> As above, if there's a method in the envelope, then it does apply.
>
> To me "doc-style SOAP" is "RESTful SOAP".
>
> > I'd like to believe know that as far as a doc-style SOAP is concerned,
it
> > slightly violates a uniform inerface constraint (when POST is used with
> > semantics of GET),
>
> If you put a method in the SOAP body, then you are completely disregarding
> the uniform interface constraint.  "slightly" doesn't quite cut it. 8-)
>
> > and also does not adhere strictly to a resource
> > identification constraint in that URI alone is not sufficient in finding
the
> > mapping to a specific representation. When combined, these two issues
seem
> > to present problems mainly to generic processors, particularly with
respect
> > to caching and security. What do you think on this ?
>
> That's good.  But also the integration/coordination/O(N)-vs-O(N^2) issue
> too.
>
> Mark.
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>
>

Received on Friday, 12 September 2003 17:44:44 UTC