cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Vinoski <vino...@iona.com>
Subject Re: REST support proposal for review
Date Fri, 08 Sep 2006 05:16:15 GMT
On Sep 7, 2006, at 10:43 PM, Oisin Hurley wrote:

>> A few comments. First, "few verbs" is not a key idea of REST.
>
> It is a very strong guideline IMO :)

Not to be overly pedantic, but Fielding [1] never mentions anything  
about interface size in his thesis. Rather, he stresses the uniform  
interface constraint and interface generality, which as I said in my  
original email naturally results in "interface smallness" as a by- 
product.

>> Second, putting the verb in the URL is a Really Bad Idea™.
>
> I would go further down the path and say - this really isn't
> allowed at all.

I fully agree, but saying it that way wouldn't have allowed me to  
include the cool trademark sign in my message. ;-)

More comments below.

>> There's much more I could say about what you've written in the  
>> wiki, but let me cut it short and simply ask this: what are the  
>> goals of having CXF "support REST"? Who or what does it benefit?  
>> What kinds of systems do you envision making use of that support?  
>> Considering these questions and their possible answers within the  
>> constraints of the REST architectural style [1] is the only way to  
>> get this truly right, IMO.
>
> I can only talk for the use case that I have direct access
> to - I have a server that maintains a memory model of a
> set of entities that can be serialized to an XML vocabulary.
> These set of entities can be influenced by a client
> application, local to the client's address space. The
> set of entities may be large, so the client loads entities
> on-demand. If changes are made on the client side, the
> changes are collated using an XML change language and
> are submitted to the server - the server applies the
> changes to the definitive set of entities that it maintains.
>
> So - the set of entities is reflected as a Resource, with
> a URL (in fact the entities themselves are also resources,
> so to load a resource, the client issues a GET).
>
> When the client issues the change request, it is couched
> as a POST accompanied by the change language document.
> The implementation on the server side receives a 'post'
> method call with an XML document as the argument - there
> is no type mapping, unmarshalling or any of that, it is
> pretty much an application protocol approach. The content
> of the POST expresses an update to the state of the
> resource.
>
> Summary: cxf supporting REST means that there is a
> way to program servants to react to HTTP as an application
> protocol, rather than as a layered protocol.

What you say about using HTTP as an app protocol -- as it was  
designed to be used, frankly -- is definitely a requirement. However,  
there's more as well -- REST also requires supporting navigation of  
application state via hyperlinks, which means that CXF has to enable  
and perhaps help the server-side application to generate the URLs  
required to identify new resources that it creates and tie servants/ 
implementations to them. Applications have to play their part, too,  
by following the semantics of HTTP, such as ensuring that GETs are  
idempotent, and ensuring that the URLs it produces for its resources  
and state aren't just always temporary or transient.

The web is actually a big distributed object system [2]. As such,  
much can be learned about how to implement the dispatching part of a  
REST system by looking at how systems like CORBA ORBs implement  
dispatching.

--steve

[1] <http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm>
[2] <http://www.w3.org/People/Connolly/9703-web-apps-essay.html>
Mime
View raw message