Re: Few questions about REST

Hi Sergey,

On Mon, Sep 15, 2003 at 09:44:28AM -0400, Sergey Beryozkin wrote:
> > 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.
> 
> So, as far as doc-lit SOAP is concerned :
> It can meet a resource identification constraint, either completely, by
> using a URI which is fully visible (at least the latest SOAP specs recommend
> it) or partially, by combining a Request URI and a control parameter like
> (SOAP)'action' into a single URI (this combination will be done by a POST
> handler and as such, a combined URI is not visible to intermediaries).

I wouldn't use "partially" there, I'd say that resources are not
identified.  I don't think there's much of a middle ground when it
comes to the resource identification constraint.

> It does not strictly meet a uniform interface constraint when it retrieves
> representations by using POST instead of GET.

Right.

> However, when a Web Method feature is combined with a SOAP Response Pattern
> (sorry, no links), that is, when an HTTP GET is issued and a doc-lit SOAP
> body is returned (not WSDL), then these key constraints are met completely.

Yes, I think so.

> I'm not sure how tools support it at the moment.
> It also probably meets other constraints, such as self-description and state
> as representation, or at least can meet them.

*can* meet them, yes.

> Can we consider doc-lit SOAP as being "mostly RESTful" ?

In general, I don't think so.  Resource identification and the uniform
interface are absolutely core to REST.  If the interface were "very
general", without being strictly "uniform" (e.g. "PROPFIND", or
"SEARCH"), but resources were identified, then I would answer "yes".
But if we're talking about very specific methods like "getInvoice",
then I'd have to answer "No".

> I'd like to ask again about late-binding. You noted earlier that integration
> costs rise significantly if a service is early-bound. Can you please explain
> what you mean ?

Just that if it's not late bound, then client software needs upgrading
whenever new services are introduced.  The opposite isn't true, however;
just because you are late bound, it doesn't mean you don't need client
upgrades to access new services.  Consider an FTP client that supports
ftp URIs; when a new scheme is introduced, it needs upgrading to be able
to use it.  It's really the combination of the uniform interface and
late-binding which is why the Web is so powerful; HTTP clients can
interact with *ANY* URI (perhaps with a proxy), because HTTP semantics
are uniform to *ALL* URI.

Something else you might want to consider, is that in an important
sense, you don't actually have a network until you're using late
binding.  Think about it. 8-)

> I thought that the main issue, as far as integration is concerned, when RPC
> method names and parameters, directly bound to some underlying objects, were
> transmitted in a message body with any subsequent change in the
> implementation requiring a new service interface.
> Doc-lit SOAP services are early-bound, but I don't see yet how this fact can
> increase integration costs. Also, it's not quite clear, how late-binding
> would decrease them.

Simply by reusing what's already out there.

> It seems a WSDL Requirement 085 allows for late-bound services to be
> designed, which looks to me as if  late-binding is mainly about dynamic
> allocation of resources.

R085 doesn't say that the URIs have to include sufficient information to
inform a client which interface can be used, which would be what is
required to mandate late binding.  It just says any URI, including
ones like http://api.google.com/search/beta2

And identification of resources doesn't necessarily mean allocation of
them.

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

Received on Monday, 15 September 2003 11:08:33 UTC