Re: Few questions about REST

Hello Mark,

Thank you for answering the questions.
More questions on the way :-)


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

How important is it for a server to follow a late-binding model ? Is it
mainly about load-balancing and hot deployment ? One possible disadvantage
is that it may cause a slower initial processing time ...

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

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

> > 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 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 ?
If so, then even doc-style SOAP-based services present an issue for
non-specialized firewalls...

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

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), 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 ?

Cheers
Sergey Beryozkin








----- Original Message -----
From: "Mark Baker" <distobj@acm.org>
To: "Sergey Beryozkin" <sberyozkin@zandar.com>
Sent: Friday, September 12, 2003 2:02 AM
Subject: Re: Few questions about REST


> On Thu, Sep 11, 2003 at 12:51:03PM -0400, Sergey Beryozkin wrote:
> > Hello Mark,
> >
> > My name is Sergey Beryozkin, I'm a Software Engineer working for Zandar
> > Technologies in Dublin.
>
> Hi Sergey,
>
> > Apologies for sending this message directly to you, please ignore it if
> > you've no time on reading it.
>
> I've got time, but I do prefer to respond to questions like this in a
> public forum or archive.  If you agree, can we copy this discussion to
> www-archive@w3.org?
>
> > I'm thinking about writing an article on the subject on how closely
> > SOAP-based web services (those exchanging documents only) can follow
REST
> > guidelines. The purpose of the article would not be to choose the best
> > approach but rather try to compare as neutrally as possible two
approaches
> > from a point of view of a software engineer who is confronted with a
choice.
> > I'd like to ask you for help in explaining few points relating to REST
> > constraints. I'm reading your weblog, I've just reread chapters 5&6 of
the
> > Fielding's dissertation, but some things are still unclear. Here're the
> > questions (all references to SOAP imply that a document , but not RPC,
style
> > is used ) :
>
> Great...
>
> > 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 all SOAP service requests are sent to a single URL which
is
> > available from the moment the first request is issued ? Does this fact
or
> > the fact that a SOAP-based service will use a new media type parameter
(or
> > SOAP Action), rather than a portion of URI, to find a handler violates
at
> > least one of REST constraints ?
>
> 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
>
> (where the specification of the stockquote scheme includes the WSDL that
> includes getStockQuote, say)
>
> instead of;
>
>   http://example.org/rpc
>
> to which getStockQuote("SUNW") is sent.
>
> Those other things you mention are concerns, and violate various REST
> constraints, but don't relate to early/late binding, I don't think.
>
> 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.
>
> > 2. HTTP verbs (POST, GET, etc) :  do they meet a uniform interface
> > constraint ?
>
> Yes.
>
> > My inderstanding of it is that a resource interface should be
> > generic enough with well-understood semantics attached to each of its
> > methods, with HTTP interface being one such example,  is it correct ?
>
> Pretty much, 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.
>
> > 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.
>
> 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.
>
> > 3. SOAP over transport protocols, like TCP/IP : how REST style can be
> > applied there ? The messages should be self-descriptive, which means
> > stateless interactions, standard methods, etc. But with TCP/IP, what
form
> > these standard methods should take ?
> > For ex, when a document is POSTed,  a RESTful service will find a
handler
> > using a URI mapping,  but what about a TCP-IP based service which is
> > accessible over a single socket (endpoint) ?  Is a TCP-IP service early
> > bound ?
>
> Not necessarily.  A RESTful use of TCP/IP would either mean building
> something HTTP-like on top, or else only using a single uniform semantic
> which is specified out of band.  For example, we could specify that any
> document arriving on TCP port 8888 was to be treated as if it arrived
> via HTTP POST.
>
> That wouldn't be as extensible as HTTP, because of the single uniform
> semantic being bound to the port, rather than an extensible set of
> methods on a single port, but that's how you'd do it.  You could also,
> for example, use port 8889, down which you shove URIs, to be treated to
> the equivalent of HTTP GET.
>
> > That's it so far :-). Sorry if the questions are unclear or trivial to
> > answer.
>
> Nope, those were very good questions.  I wish I heard more like them 8-)
>
> > Thanks for your time
>
> My pleasure.
>
> Mark.
> --
> Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
>
>

Received on Friday, 12 September 2003 12:58:57 UTC