cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <dan.diepho...@mulesource.com>
Subject Re: Feedback on RESTful services in CXF
Date Tue, 28 Aug 2007 20:33:38 GMT
Trenaman, Adrian wrote:
> First problem: I didn't realise that I needed to have a
> package-info.java in the package. Without this, my Person object (which
> represents the payload of the PUT) has null contents in the serverside
> code. Through a lot of trial and error I discovered that I hadn't
> included package-info.java file in the Java package (it's still not
> clear to me why I should need it...). 
>
>   
I hate how JAXB defaults to UNQUALIFIED, its rather silly.

Did you file a JIRA for this? Sounds like a bug in the schema parsing code.
> Second problem: for some reason CXF insists that the payload document's
> root element is not prefixed with an XML namespace prefix. For example;
> the following valid XML results in a server-side NullPointerException.
>  
Did you file a JIRA for this? Sounds like a bug in an interceptor. I 
would like to see the stack trace and see if we can get this fixed for 
2.0.2.
>  
> Third problem: in the update scenario, if I send the XML to /people/123
> then the ID (123) gets injected into the payload over the existing id
> (42). I think this behaviour, where we override the data in the payload,
> may lead to a lot of confusion: what if someone wants to update the id
> (or is that RESTful heresy)? what if someone has sent the payload to the
> wrong HTTP URL? Would it be better if we simply reject the call if the
> "injecting" parameters don't match the payload?
>   
This is part of the problem of trying to fulfill the WSDL2 HTTP Binding. 
I should probably look up the details of whats required here.

<pontification>
My original intention was to support the WSDL2 HTTP binding, but its 
ended up in soooo many confusing things that I'm beginning to think the 
whole HTTP binding as it currently stands is a mistake.

After playing with Jersey (the Sun JSR 311 impl) for a bit, I'm much 
more inclined to go down that route. The WSDL model just doesn't work 
with REST at all. Right now we have all sorts of weirdness - 
wrapped/unwrapped mode being the biggest one. Its a source of 
never-ending confusion to users.

Which brings us to the question - how do you properly integrate RESTful 
support into a web service framework which operates on a WSDL model :-)

Regarding the future of our REST support, I suppose we have two roads to 
go down:
1. Build our own JSR 311 impl. Cons: mapping the internal WSDL like 
model to a RESTful one
2. Create bridges to something like Jersey. i.e. we would just proxy the 
request. Although at this point, I'm a bit confused as to what value 
we're really providing.

Thoughts?
</pontification>

- Dan

-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog



Mime
View raw message