cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Liu, Jervis" <>
Subject RE: REST support proposal for review
Date Fri, 08 Sep 2006 08:59:57 GMT
Comments in-line.


> -----Original Message-----
> From: Vinoski, Stephen 
> Sent: Friday, September 08, 2006 4:56 AM
> To:
> Subject: Re: REST support proposal for review 
> Hi Jervis,
> A few comments. First, "few verbs" is not a key idea of REST. 
> Rather,  
> the REST architectural style promotes a uniform interface 
> constraint,  
> where all resources support the same exact interface. The interface  
> ends up being small only because it has to be general purpose, not  
> because REST requires it to be small. For HTTP-based systems, the  
> REST uniform interface is the collection of HTTP verbs, 
> primarily GET  
> and POST.
> Second, putting the verb in the URL is a Really Bad Idea™. URIs  
> identify resources and application states, not operations. The verb  
> is specified by the protocol. If you're really going to 
> support REST,  
> you're probably going to implement it using HTTP, in which case you  
> need a raw HTTP binding if you don't already have one. But then that  
> in turn begs the question of what such a binding would offer over a  
> plain ol' servlet. Alternatively, REST can be implemented using  
> protocols other than HTTP, but I'm not sure going down that path  
> would buy you anything.
> 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.

Yes, this is the exact question we have to answer before we make any move and I am sorry that
I should have stated the goals more clearly on the wiki. My proposal is by no means to invent
a pure REST programming model in CXF. The reason is obvious, this has been an on-going topic
and I do not see an end going to happen in the near future, at least in the time frame of
CXF M1 or M2 ;-).  I would therefore to add more REST flavors into CXF for the time being.
At least we can claim that CXF can serve and consume services in a more "RESTful" way.  I
would be very careful of any attempts in CXF to tackle a complex REST programming model though,
as I do not see any winning ideas yet of how exactly it should look like.

So the plan was to tackle this in to stages. The long term goal of course will be a full REST
support: semantics, a wildly accepted programming model etc. In the short term, For CXF M1
and M2, I will be more than happy to see following scenarios are being addressed. 

1. CXF can serve services in a RESTful way:

Given an URL of , CXF returns an xml response


I know your guys are going to hate the "getCustomer" verb encoded in URI, and I definitely
agree that this, together with the query style (?id=abc), are not very RESTful semantics.
However, we can look into this problem from two aspects:

a. the "getCusomter" verb does not have to be appeared in URI. You can change it to,
the JAX-WS provider approach proposed on wiki can perfectly support both. This is because
with the provider approach, CXF does not do anything like type mapping, unmarshalling/marshalling,
it just gets raw data from http transport then pass it to provider implementation. It is the
provider implementation (which is the application code)'s responsibility to parse the URI
as well as query parameters. This is very similar to the "application protocol approach" Oisin

b. using "getCustomer" as the default mapping can be helpful when we port existing Web service
to REST service. Imaging I have an existing soap/http based service that has two operations,
getCustomer(String id) and udpateCustomer(Customer), now I want to expose this as REST service,
how can CXF help me in this case? A default mapping from the SEI method getCutomer(String
id) to REST resource url would make a REST
service flying straight away. Though I admit the URI does not look very RESTful, but again,
with some extra efforts, we can always map the URI in a different way. For example, through
annotations or a side configuration. 

Note: even though I believe (b) is a very valid use case and will be a very much required
feature, I suggest we support (a) first. Supporting (b) requires CXF server side working with
SEI, which is more complex than using provider. Please refer to the wiki for more detailed

2. CXF client can consume services in a RESTful way. 

CXF client needs to help users to construct HTTP GET and POST request with necessary data
and send it to target REST URI.

When a response received like below:
HTTP/1.1 200 OK
X-Powered-By: Servlet/2.5
Content-Type: text/xml
Connection: close

<?xml version="1.0" encoding="UTF-8"?>

CXF client can return the xml document to users.

A client side JAX-WS dispatcher approach should satisfy this requirement.

There is a long discussion in Tuscany mailing list on how to support REST in sca, some initial
progresses were made based Axis2.
I believe with (1) and (2) achieved, we will be in a good position to offer a more elegant
REST support that can be used in Tuscany than Axis2 currently does. I have created JIRA
and to target (1) and (2).

Once this basic scenario works, we shall come back and review the implementation to see how
we can support more scenarios and more RESTful semantics. 

> --steve
> [1] <>
> On Sep 7, 2006, at 11:37 AM, Liu, Jervis wrote:
> > Hi, I have put the REST support proposal on wiki for your review.  
> > Any comments are welcome.
> >
> >
> >
> > Cheers,
> > Jervis

View raw message