cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liu, Jervis" <j...@iona.com>
Subject RE: REST support proposal for review
Date Fri, 08 Sep 2006 18:08:16 GMT


> -----Original Message-----
> From: Hurley, Oisin 
> Sent: 2006?9?8? 20:40
> To: cxf-dev@incubator.apache.org
> Subject: Re: REST support proposal for review 
> 
> 
> [deletia]
> 
> > What you say about using HTTP as an app protocol -- as it was  
> > designed to be used, frankly -- is definitely a requirement.
> 
> +1 - this is step 1
> 
> > 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.
> 
> +1
> 
> > 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.
> 
> +1 - wow I seem to be very agreeable today.
> 
> It's the enforcement of the idempotency and the persistent of URLs  
> that are the
> pieces that most development might miss out on. If there was 
> some way  
> to automate
> the assurance of these semantic elements, then you could say that  
> something was
> truly REST-supportive. Without a formal definition of state  
> representation in the
> programming language (or even an informal one :) then this is always  
> going to be
> delivered on a case-by-case basis and is prone to error.
> 
> I guess for cxf that the priority is getting the 'application  
> protocol' support
> in place to deliver payload to a 'servant' with information 
> about the  
> HTTP
> context. This is what was available in Celtix 1.0 and is in use :)

Hi Oisin, would you mind elaborating into more details on what will be involved to get the
"application protocol" support in place? Would the JAX-WS provider approach  I described early
satisfy the requirement? Also regarding your point of "with information about the HTTP context",
I will make the URI path info available to provider, I am not sure if there is anything else
needed to proceed REST. For example, Sergey raise a point early that HTTP GET is actually
a hint to perform a get operation. If this is the case, we need to make HTTP method available
to JAX-WS provider as well. 
> 
> cheers
>   --oh
> 

Mime
View raw message