cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <>
Subject Re: REST questions
Date Mon, 30 Oct 2006 22:35:01 GMT
James Mao wrote:
> Hi Dan,
>> 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>
> If it's GET, why it need to build document,  can it process the 
> parameters and invoke the method directly?
Well a couple reasons. First, this isn't how the WSDL 2 spec specifies 
things. Second, If we synthesize a document we can do databinding a lot 
easier. Imagine a scenario where part of the information in the Customer 
object is supplied via the URI and part of it is supplied via the XML. 
This allows us to merge things.
> I have just checked in the GET support for the SOAP1.2, but finally i 
> found that both SOAP1.1 and XML binding works as well.
> So, currently i think all the hello_world demos can get the result 
> even from the browser, just use the uri like this:
> http://localhost:9090/SoapContext/SoapPort/sayHi
> http://localhost:9090/SoapContext/SoapPort/greetMe/me/CXF
> If the method name is not exist, you will get the fault message.
> Currently i just not check the parameter name, just get the parameter 
> value, so currently just assume that the parameter is given by order, 
> later if we add the parameter name check, user can ignore the 
> parameter order.
> And of course GET only support simple type.
> I have passed through all the unmahsall interceptors and placed in an 
> URIMappingInterceptor to retrive the parameters and operation name.
Where is this interceptor? I don't see it anywhere...

- Dan

Dan Diephouse
Envoi Solutions

View raw message