cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oisin Hurley <>
Subject Re: REST support proposal for review
Date Fri, 08 Sep 2006 12:39:55 GMT

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


> 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  
context. This is what was available in Celtix 1.0 and is in use :)


View raw message