WS-RF, REST

On Mon, Jul 05, 2004 at 11:24:06AM -0700, David Orchard wrote:
> > I just don't see how one could consider WS-RF RESTful .. can you 
> > expand more please?
> 
> Sure, but check out the constraints described in Roy's thesis and compare those with WS-RF.  At a high level, I think they think about the world in the same way.  WS-RF views it's world as a set of properties that represent the state of resources, which are exchanged using representations by a constrained protocol.
>
>  My take on it from a direct comparison of REST to WS-RF is RF:
> - uses constrained operations to interact with resources (the get/insert/update/delete)

That's for individual properties, not for the state of the resource as
a whole, which WS-RP doesn't explicitly address.  Also, the semantics
are not uniform since they're only useful for properties (for the same
reason that WebDAV PROPFIND is not not uniform).  It's not too far off
though.

> - uses hypertext as the engine of state transfer.  Hypertext really meaning "active documents" where active means they have "links" in them.  And I consider EPRs to be "links".

Sure, but AFAICT, resource properties don't return EPRs.  i.e. WS-RP
doesn't appear to have an application engine.  It's one of those
obvious things, ala caching of "get", but because the spec doesn't
constrain it, the implicit style doesn't appear to be so constrained.
Consider that somebody could perhaps integrate BPEL and WS-RF, which
would be introducing a non-hypermedia application engine.

> - is self-describing (xml+soap+ws-addressing action).

The whole bit about renewable references suggests to me that WS-RF is
stateful, which would make it not self-descriptive by definition.  I
don't think any of those specs you mentioned have very much to do with
self-description.

> - is layered client server

I didn't see any explicit layering there; did I miss something?

> - It doesn't follow the caching aspect of REST, where the cache control logic is built into the protocol, but that's usually not quoted as part of being "RESTful".  FWIW, why WS-RF doesn't want caching for the GET requests is beyond me.  

Yup.

> As I showed in my "WS-REST" proposal to WS-RF, there is a pretty straightforward binding of WS-RF messages to HTTP verbs, the exception being mapping some of the WS-Addressing asynch parts onto HTTP.  

Sounds interesting.  Where can I find a point to "WS-REST"?  Google
turns up nothing.

> If people want to dispute whether WS-RF is "RESTful" or not, I'd prefer it if they gave concrete technical reasons rather than "I don't think so" or "doesn't feel like it to me".  The constraints that make up REST are rigorously defined and WS-RF can be directly evaluated against them.  For example, I could see an argument being used that says something like: WS-RF isn't RESTlike because EPRs aren't links.  They aren't links because the use of reference properties takes the resource "off the web".   Now I have counter-arguments to that in mind, but that's the kind of argument I'd expect.  

You mean a principled architectural evaluation of a proposed software
architectural style?  On www-ws-arch?!?!  Been there, tried that, got the
bruises.  Best of luck though! 8-)

> > > I like the idea of formally specifying an extension/feature/property
> > > that a service provider could put in their WSDL to say "do x to get
> > > metadata".  It has the classic bootstrap problem though.
> > 
> > Right .. so I view WS-MetadataExchange like Java's Class object or
> > COM's QueryInterface method. Every Web service must support being
> > asked "tell me about yourself" .. just like in Java you can ask any
> > object for its class and from that get all the metadata necessary
> > to execute something in it. That of course does not mean that the
> > Web service implementor has to handle those messages himself (or
> > herself); the "infrastructure" has to do that.
> > 
> 
> I think that's a great way of looking at it.

+1.  See also;

http://www.w3.org/DesignIssues/DistObjApps.html

>  There's cases where you get the metadata from somewhere other than the object - like a registry - and cases where you discover the metadata from the object/resource.  There is a choice to be made: whether to make a new operation for getting the metadata, or re-using existing operations/protocol and using some kind of URI.  There are 2 different extensibility points for the functionality.  There is appeal to both.  
>
> I do think it is a shame that trying to bridge the "arbitrary verbs" versus "constrained verbs" is really hard.  Each optimizes for different cases.  I think that arbitrary verbs optimizes for the "update/write of things with side-effects" and that constrained verbs optimizes for the read case.

I believe that to be incorrect.

In optimization terms, constrained verbs are optimized for the case
where integration simplicity is paramount, particularly for interactions
between untrusted parties.  I don't believe that unconstrained verbs are
optimized for anything; if you ask me (as an architect of two very large
integration projects, one CORBA based and the other Web based), they make
large scale integration practically impossible (yes, the CORBA project
failed 8-).

>  And both are really important.   I hate having to come up with a new verb every time I change my schema (the abitrary verbs), and I hate having to shoe-horn the updates with side-effects - like setTimeOut(0) - into a generic update operation.

Why wouldn't PUT work for setTimeOut(0)?  Seems a completely natural
fit to me.

But I'm not saying there's not shoehorning to be done; try doing the
equivalent of "UPDATE foo=bar WHERE baz>1" RESTfully as an example.  I'm 
just saying there's a *WHOLE* lot less of it to be done than you appear
to believe.  I've only ever had problems being uniform on *two*
occasions, and both times they were basically equivalent to that UPDATE
example.

Cheers,

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

  Seeking work on large scale application/data integration projects
  and/or the enabling infrastructure for same.

Received on Monday, 5 July 2004 16:41:06 UTC