cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Vinoski <>
Subject Re: REST questions
Date Mon, 30 Oct 2006 22:49:09 GMT
On Oct 29, 2006, at 10:39 PM, Dan Diephouse wrote:
> Hi Steve,
> Steve Vinoski wrote:
>> Hi Dan,
>> So far the CXF REST support is looking good. I have three  
>> questions about where it might go next.
>> 1. Can you explain in more detail how incoming data for a REST- 
>> style request is mapped to the arguments that the resource  
>> implementation receives, and how return values are mapped to  
>> responses?
> Parameters in the resource name (i.e. "id" in /customers/{id}) get  
> mapped to the corresponding schema element. For instance, if this  
> is our schema:
> <element name="getCustomer">
> <complexType>
> <sequence>
> <element name="id" type="xsd:string"/>
> </sequence>
> </complexType>
> </element>
> Then the http binding will construct a Document with a getCustomer  
> root element and create an <id> element with the {id} from the URI.  
> So a GET to /customers/123 results in:
> <getCustomer>
> <id>123</id>
> </getCustomer>

What about more complex arguments? How much mapping from the incoming  
content-type to Java does this try to do?

>> 2. You've addressed the "verb" part of REST via the annotations,  
>> and partly addressed the "noun" part via URI templates. Since REST  
>> stresses "hypermedia as the engine of application state," have you  
>> any plans to make it easy for resource implementations to obtain  
>> URIs for other co-located resources, for example to enable  
>> resource implementations to easily return documents containing  
>> URIs for those other resources?
> Yes! The question is do we need some formal notion for this? I.e. I  
> could do:
> @HttpHeader(name="NewURI") String addCustomer(Customer c) {
> ...
> return "/customers/123"
> }
> Or you could return a document with the URI.
> Two downsides with this though:
> 1. The host name isn't included (we could have interpolate when we  
> see {host} if wanted...)
> 2. No way to really turn this around on the client side into  
> something we can use to access the new customer easily.

The reason I ask is that if you mention the URL for a given resource  
once in an annotation, and then have to mention it again elsewhere in  
your code in reference to that resource, the chances are quite good  
that the multiple mentions of the URL will get out of sync somewhere  
down the road.

>> 3. Will you be doing anything in the CXF REST support to help a  
>> resource handle multiple content-types, and if so, what?
> Yes. We could use the XFire databinding library - Aegis - to do  
> this. Although it is pretty tied to XML. It certainly wouldn't be  
> that hard to write a DataBinding implementation that coudl  
> serialize JPEGs, HTML, etc. Just a matter of time...

This raises the same question as above: how are such things mapped  
into Java, and how does one control those mappings?

> I also have a JSON binding in the works. But this is done by  
> creating a stax implementation that uses JSON underneath. I should  
> be able to demo this in a week as I have the reader side done and  
> just need to finish the writing side.



> - Dan
> -- 
> Dan Diephouse
> Envoi Solutions

View raw message