cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <>
Subject Re: REST questions
Date Wed, 01 Nov 2006 18:24:11 GMT
Apologies for the delay...

Steve Vinoski wrote:
> 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?
Really it can only handle primitive type things at this point. Anything 
that can be represented by an <element> with text... Ultimately it is up 
to the databinding layer to handle the document though and turn it into 
something else.
>>> 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.
Good point. So do we integrate in some URL reference mechanism? What 
would such a thing look like? I'm not sure...  I've thought about it a 
little and I'm not sure that the Service class with operations maps 
really well to using URI references. Any ideas?

I would like to stress that mapping operations to a resource is only one 
way to do things. People could create a more rigid api that people have 
to conform to that more closely maps to resources. I kind of feel the 
rest annotations are a nice 80/20 solution though...
>>> 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?
Well in Aegis you can do something like...

type = new ImageType();

So in that case it would be managed by the class name. However you can 
also supply an xml mapping file with aegis which says which type to use. 
There are many ways we could control the mapping...
>> 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.
> Cool.
So JSON is a good example of a different content type. I'm not sure the 
exact mechanism we should use to trigger a content type change at this 
point though. It could be done via annotations (ick), but I would 
probably prefer some other way (wsdl extensors? xml configuration? A 
switch somewhere?) to control what the default content type is...

Lots of things to play around with yet. I don't really have answers for 
all these things yet, however I think creating some linkability 
mechanism is probably very high on the list to figure out....

- Dan

Dan Diephouse
Envoi Solutions

View raw message