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 10:30:02 GMT


> -----Original Message-----
> From: Beryozkin, Sergey 
> Sent: Friday, September 08, 2006 5:49 PM
> To: cxf-dev@incubator.apache.org
> Subject: Re: REST support proposal for review 
> 
> 
> Hi
> 
> "> 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.
> 
> +1 to what Oisin said there. It captures the key requirement 
> in a single sentence.
> 
CXF server side JAX-WS provider offers a preliminary support for this. As long as both HTTP
GET and POST can be handled by CXF http transport layer(tackled by jira http://issues.apache.org/jira/browse/CXF-43),
and the request URI path info can be accessed from provider implementation(tackled by jira
http://issues.apache.org/jira/browse/CXF-42), the provider should have all information it
needs to react to HTTP.

> "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 too. Depending on the content type a client expects there 
> should be a way to convert a response source into a 
> navigatble HTML for 
> ex. Perhaps it's a job for a custom handler. I'm not sure how 
> this can be generalized. It's also still probably a job for the top 
> level resource provider implementation to ensure an (XML) 
> source it returns is navigatable.
> 
Using JAX-WS provider approach proposed, this is done by server side provider implementation.
For example, given an URL of http://localhost/customerservice/customers, provider impl should
return an xml document like below:

<Customers>
  <Customer>http://localhost/customerservice/customer/john</Customer>
  <Customer>http://localhost/customerservice/customer/eric</Customer>
  <Customer>http://localhost/customerservice/customer/tony</Customer>
</Customers>

On the receiving of this xml on client side, client can navigate to customer john by requesting
URI http://localhost/customerservice/customer/john, this in turn will return an xml document
:

<Customer>
  <CustomerName>John</CustomerName>
  <CustomerID>ABC</CustomerID>
</Customer>


> Interesting thing here is how a client can use a navigatable 
> XML. IMHO REST approach is still used by (arguably) a minority of 
> projects where it can be a better fit is that it requres what 
> can be thought as a difficult programming model : do HTTP invocation, 
> check response codes, parse XML manually, etc...

You are right. The scenario I described above works, but it is a "difficult programming model"
, involves in a lot of manual coding in the application implementation. 

> JAX-WS can somehow make it easier by relying on JAXB when 
> possible. However it's likely many would still be quite more 

This is where SEI support (both on CXF client side and server side, please refer to the proposal
wiki) starts play its role. Under certain situations, we can use JAX-WS to dispatch the REST
source request to a certain SEI method and using JAXB to marshall and unmarshall xml data.

However, there are several things we have not figured out yet, both conceptually and the implementation
details, so I suggest we tackle JAX-Ws provider/dispatcher first as a preliminary support
to REST programming, then come back to more complex scenarios later.

> comfortable 
> with stubs which will do the 'difficult' job.
> 
> Please have a look at
> http://weblogs.java.net/blog/mhadley/archive/2006/05/index.html
> and
> http://weblogs.java.net/blog/mhadley/archive/2006/08/index.html
> 
> If cxf supported this client-side mode of working with 
> HTTP-based services (in addition to JAXB one : 
> http://weblogs.java.net/blog/mhadley/archive/2006/03/index.htm
> l) then it'd really make REST an easy step, IMHO. This is where stubs 
> would be good in that that they could serve as a first step : 
> they do all the 'difficult' job and more importantly make it easy to 
> 'navigate' through XML
> 
> It'd be then up to a developer to get rid of stubs if he/she 
> gets convinced in the benefits of using REST....
> 
> 
> Cheers, Sergey
> 
> 
> 
> 
> 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