You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cxf.apache.org by James Mao <ja...@iona.com> on 2006/10/25 05:39:05 UTC
Re: svn commit: r467080 [1/2] - in /incubator/cxf/trunk/rt: bindings/
bindings/http/ bindings/http/src/ bindings/http/src/main/ bindings/http/src/main/java/
bindings/http/src/main/java/org/ bindings/http/src/main/java/org/apache/
bindings/http/src/main/jav...
Hi Dan,
What's the 'HTTP binding' for? is it just for REST?
If so why call it 'HTTP binding'? can we call it 'REST binding'?
'HTTP' sounds just like a transport.
The 'HTTP binding' is use HTTP transport, right? so we have 'HTTP over
HTTP'? sounds weird.
Another question is that current CXF REST support is based on JAX-WS,
why we need the 'HTTP binding' to expose the JAX-WS service again?
Thanks,
James.
> Author: dandiep
> Date: Mon Oct 23 11:52:16 2006
> New Revision: 467080
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=467080
> Log:
> Add an "HTTP binding" which uses the Java Rest Annotations (new project at the
> Codehaus which James Strachan and I started) to expose JAX-WS services as REST
> style services.
>
> Thanks to Guillaume Nodet who supplied the IriDecoderHelper class which was
> indispensible.
>
> Currently this just includes:
> o simple server side functionality to take JAX-WS operations and expose them
> as resources using the @HttpResource annotation and @Get/@Put/@Post/@Delete.
> o Ability to take URI parameters and construct an incoming XML document
> according to WSDL 2 spec
> o Ability to take URI parameters and an incoming XML document and merge them
>
> Other things in this commit:
> o Fixed the JAXBDataBinding so we didn't twice initialize the Types if the
> WSDLServiceBuilder already did it.
> o Added support for recognizing unwrapped operations in XMLOutInterceptor
>
>
Re: About the REST/HTTP Binding... [was Re: svn commit: r467080 ...]
Posted by Brandon Smith <br...@16cards.com>.
+1 for PUT = update and POST = create.
http://www.elharo.com/blog/software-development/web-development/2005/12/08/post-vs-put/
Brandon Smith
On 10/29/06, Dan Diephouse <da...@envoisolutions.com> wrote:
>
> Hi James,
>
> James Mao wrote:
> > Hi Dan,
> >
> > Thanks for your explanations, that make sense to me.
> > I review the code, and i wondering if the PUT should use addCustomer,
> > and the POST should use updateCustomer?
> > One thing i still can not understand is that the difference between
> > REST POST and the normal POST? are they same?
> >
> As far as I understand, POST is for adding, and PUT is for updating.
> > In @GET, how you map the uri to the operation name? through the
> > annotation? and i guess in @GET method we can only support simple
> > type, right?
> Yes, through the annotation, and yes it only maps simple types.
> > What's the mechanism to map the uri to parameters? it's the name-value
> > pair or just value?
> >
> WSDL 2.0 specifies a mechanism where by we actually synthesize an
> incoming document and map the parameter to the it based on the schema. I
> blogged a little bit about it here:
>
> http://netzooid.com/blog/2006/10/27/cxf-rest-support/
> > I'm thinking of support GET for SOAP1.2, but finally i found that it
> > may work for all bindings (SOAP1.1 SOAP1.2 and XML),
> > The scenario I'm imaging is that for the normal POST webservice, we
> > can use GET to retrieve the result through GET as long as the
> > parameters are simple type. sort of RPC style, but should work.
> > for example, for the hello_world sayHi/greetMe method, we normally
> > write a client code to invoke the service, since now we support GET,
> > you don't need to do so, you can even use browser to retrieve the
> > result, just use the URI
> > http://localhost:9000/SoapContext/SoapPort/sayHi or
> > http://localhost:9000/SoapContext/SoapPort/greetMe/requestType/Dan or
> > http://localhost:9000/SoapContext/SoapPort/greetMe?requestType=Dan
> >
> > Thoughts?
> Is this how the SOAP 1.2 HTTP GET binding is supposed to work? I took a
> quick look at the spec, but it wasn't immediately clear what is supposed
> to happen with SOAP over GET.
>
> I don't see the harm in doing such a thing, but you might be able to
> just reuse the HTTP-binding module. I'd like to support other ways of
> mapping services to HTTP without annotations. One of these ways would be
> to map things based on just some simple rules - if the operation name
> starts with get its a GET operation, if its a complex type, a POST is
> required, etc...
>
> >
> > -James
> >> Hi James,
> >>
> >> While it could be called a REST binding, REST is an architectual
> >> style, not a specific implementation. When we talk about doing REST
> >> style services, usually we're talking about doing HTTP. HTTP is a
> >> protocol just like SOAP. We map operations to resources and http
> >> headers to parameters.
> >>
> >> One of the goals is to support the WSDL 2 HTTP binding [1] (which is
> >> part of where the name comes from too). While CXF has some basic
> >> XML/HTTP support it doesn't support the full range of things needed.
> >> For instance, I can't easily map URIs and verbs to operations. With
> >> the Java REST annotations which I've been working on, this is fairly
> >> trivial:
> >>
> >> @Get
> >> @HttpResource(location="/customers/{id}")
> >> public Customer getCustomer(String id) { .. }
> >>
> >> I can easily map an operation to any URI and also to any verb via
> >> @Get/@Post/@Delete/@Put.
> >>
> >> Does that help answer your questions?
> >>
> >> - Dan
> >>
> >> 1. http://www.w3.org/TR/wsdl20-adjuncts/#http-binding
> >> 2. http://jra.codehaus.org
> >>
> >> James Mao wrote:
> >>
> >>> Hi Dan,
> >>>
> >>> What's the 'HTTP binding' for? is it just for REST?
> >>> If so why call it 'HTTP binding'? can we call it 'REST binding'?
> >>> 'HTTP' sounds just like a transport.
> >>> The 'HTTP binding' is use HTTP transport, right? so we have 'HTTP
> >>> over HTTP'? sounds weird.
> >>>
> >>> Another question is that current CXF REST support is based on
> >>> JAX-WS, why we need the 'HTTP binding' to expose the JAX-WS service
> >>> again?
> >>>
> >>> Thanks,
> >>> James.
> >>>
> >>>> Author: dandiep
> >>>> Date: Mon Oct 23 11:52:16 2006
> >>>> New Revision: 467080
> >>>>
> >>>> URL: http://svn.apache.org/viewvc?view=rev&rev=467080
> >>>> Log:
> >>>> Add an "HTTP binding" which uses the Java Rest Annotations (new
> >>>> project at the
> >>>> Codehaus which James Strachan and I started) to expose JAX-WS
> >>>> services as REST style services.
> >>>> Thanks to Guillaume Nodet who supplied the IriDecoderHelper class
> >>>> which was
> >>>> indispensible.
> >>>>
> >>>> Currently this just includes:
> >>>> o simple server side functionality to take JAX-WS operations and
> >>>> expose them
> >>>> as resources using the @HttpResource annotation and
> >>>> @Get/@Put/@Post/@Delete.
> >>>> o Ability to take URI parameters and construct an incoming XML
> >>>> document
> >>>> according to WSDL 2 spec
> >>>> o Ability to take URI parameters and an incoming XML document and
> >>>> merge them
> >>>>
> >>>> Other things in this commit:
> >>>> o Fixed the JAXBDataBinding so we didn't twice initialize the Types
> >>>> if the WSDLServiceBuilder already did it.
> >>>> o Added support for recognizing unwrapped operations in
> >>>> XMLOutInterceptor
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com
> http://netzooid.com/blog
>
>
Re: About the REST/HTTP Binding... [was Re: svn commit: r467080 ...]
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi James,
James Mao wrote:
> Hi Dan,
>
> Thanks for your explanations, that make sense to me.
> I review the code, and i wondering if the PUT should use addCustomer,
> and the POST should use updateCustomer?
> One thing i still can not understand is that the difference between
> REST POST and the normal POST? are they same?
>
As far as I understand, POST is for adding, and PUT is for updating.
> In @GET, how you map the uri to the operation name? through the
> annotation? and i guess in @GET method we can only support simple
> type, right?
Yes, through the annotation, and yes it only maps simple types.
> What's the mechanism to map the uri to parameters? it's the name-value
> pair or just value?
>
WSDL 2.0 specifies a mechanism where by we actually synthesize an
incoming document and map the parameter to the it based on the schema. I
blogged a little bit about it here:
http://netzooid.com/blog/2006/10/27/cxf-rest-support/
> I'm thinking of support GET for SOAP1.2, but finally i found that it
> may work for all bindings (SOAP1.1 SOAP1.2 and XML),
> The scenario I'm imaging is that for the normal POST webservice, we
> can use GET to retrieve the result through GET as long as the
> parameters are simple type. sort of RPC style, but should work.
> for example, for the hello_world sayHi/greetMe method, we normally
> write a client code to invoke the service, since now we support GET,
> you don't need to do so, you can even use browser to retrieve the
> result, just use the URI
> http://localhost:9000/SoapContext/SoapPort/sayHi or
> http://localhost:9000/SoapContext/SoapPort/greetMe/requestType/Dan or
> http://localhost:9000/SoapContext/SoapPort/greetMe?requestType=Dan
>
> Thoughts?
Is this how the SOAP 1.2 HTTP GET binding is supposed to work? I took a
quick look at the spec, but it wasn't immediately clear what is supposed
to happen with SOAP over GET.
I don't see the harm in doing such a thing, but you might be able to
just reuse the HTTP-binding module. I'd like to support other ways of
mapping services to HTTP without annotations. One of these ways would be
to map things based on just some simple rules - if the operation name
starts with get its a GET operation, if its a complex type, a POST is
required, etc...
>
> -James
>> Hi James,
>>
>> While it could be called a REST binding, REST is an architectual
>> style, not a specific implementation. When we talk about doing REST
>> style services, usually we're talking about doing HTTP. HTTP is a
>> protocol just like SOAP. We map operations to resources and http
>> headers to parameters.
>>
>> One of the goals is to support the WSDL 2 HTTP binding [1] (which is
>> part of where the name comes from too). While CXF has some basic
>> XML/HTTP support it doesn't support the full range of things needed.
>> For instance, I can't easily map URIs and verbs to operations. With
>> the Java REST annotations which I've been working on, this is fairly
>> trivial:
>>
>> @Get
>> @HttpResource(location="/customers/{id}")
>> public Customer getCustomer(String id) { .. }
>>
>> I can easily map an operation to any URI and also to any verb via
>> @Get/@Post/@Delete/@Put.
>>
>> Does that help answer your questions?
>>
>> - Dan
>>
>> 1. http://www.w3.org/TR/wsdl20-adjuncts/#http-binding
>> 2. http://jra.codehaus.org
>>
>> James Mao wrote:
>>
>>> Hi Dan,
>>>
>>> What's the 'HTTP binding' for? is it just for REST?
>>> If so why call it 'HTTP binding'? can we call it 'REST binding'?
>>> 'HTTP' sounds just like a transport.
>>> The 'HTTP binding' is use HTTP transport, right? so we have 'HTTP
>>> over HTTP'? sounds weird.
>>>
>>> Another question is that current CXF REST support is based on
>>> JAX-WS, why we need the 'HTTP binding' to expose the JAX-WS service
>>> again?
>>>
>>> Thanks,
>>> James.
>>>
>>>> Author: dandiep
>>>> Date: Mon Oct 23 11:52:16 2006
>>>> New Revision: 467080
>>>>
>>>> URL: http://svn.apache.org/viewvc?view=rev&rev=467080
>>>> Log:
>>>> Add an "HTTP binding" which uses the Java Rest Annotations (new
>>>> project at the
>>>> Codehaus which James Strachan and I started) to expose JAX-WS
>>>> services as REST style services.
>>>> Thanks to Guillaume Nodet who supplied the IriDecoderHelper class
>>>> which was
>>>> indispensible.
>>>>
>>>> Currently this just includes:
>>>> o simple server side functionality to take JAX-WS operations and
>>>> expose them
>>>> as resources using the @HttpResource annotation and
>>>> @Get/@Put/@Post/@Delete.
>>>> o Ability to take URI parameters and construct an incoming XML
>>>> document
>>>> according to WSDL 2 spec
>>>> o Ability to take URI parameters and an incoming XML document and
>>>> merge them
>>>>
>>>> Other things in this commit:
>>>> o Fixed the JAXBDataBinding so we didn't twice initialize the Types
>>>> if the WSDLServiceBuilder already did it.
>>>> o Added support for recognizing unwrapped operations in
>>>> XMLOutInterceptor
>>>>
>>>>
>>>
>>>
>>
>>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
Re: About the REST/HTTP Binding... [was Re: svn commit: r467080 ...]
Posted by James Mao <ja...@iona.com>.
Hi Dan,
Thanks for your explanations, that make sense to me.
I review the code, and i wondering if the PUT should use addCustomer,
and the POST should use updateCustomer?
One thing i still can not understand is that the difference between REST
POST and the normal POST? are they same?
In @GET, how you map the uri to the operation name? through the
annotation? and i guess in @GET method we can only support simple type,
right?
What's the mechanism to map the uri to parameters? it's the name-value
pair or just value?
I'm thinking of support GET for SOAP1.2, but finally i found that it may
work for all bindings (SOAP1.1 SOAP1.2 and XML),
The scenario I'm imaging is that for the normal POST webservice, we can
use GET to retrieve the result through GET as long as the parameters are
simple type. sort of RPC style, but should work.
for example, for the hello_world sayHi/greetMe method, we normally write
a client code to invoke the service, since now we support GET, you don't
need to do so, you can even use browser to retrieve the result, just use
the URI http://localhost:9000/SoapContext/SoapPort/sayHi or
http://localhost:9000/SoapContext/SoapPort/greetMe/requestType/Dan or
http://localhost:9000/SoapContext/SoapPort/greetMe?requestType=Dan
Thoughts?
-James
> Hi James,
>
> While it could be called a REST binding, REST is an architectual
> style, not a specific implementation. When we talk about doing REST
> style services, usually we're talking about doing HTTP. HTTP is a
> protocol just like SOAP. We map operations to resources and http
> headers to parameters.
>
> One of the goals is to support the WSDL 2 HTTP binding [1] (which is
> part of where the name comes from too). While CXF has some basic
> XML/HTTP support it doesn't support the full range of things needed.
> For instance, I can't easily map URIs and verbs to operations. With
> the Java REST annotations which I've been working on, this is fairly
> trivial:
>
> @Get
> @HttpResource(location="/customers/{id}")
> public Customer getCustomer(String id) { .. }
>
> I can easily map an operation to any URI and also to any verb via
> @Get/@Post/@Delete/@Put.
>
> Does that help answer your questions?
>
> - Dan
>
> 1. http://www.w3.org/TR/wsdl20-adjuncts/#http-binding
> 2. http://jra.codehaus.org
>
> James Mao wrote:
>
>> Hi Dan,
>>
>> What's the 'HTTP binding' for? is it just for REST?
>> If so why call it 'HTTP binding'? can we call it 'REST binding'?
>> 'HTTP' sounds just like a transport.
>> The 'HTTP binding' is use HTTP transport, right? so we have 'HTTP
>> over HTTP'? sounds weird.
>>
>> Another question is that current CXF REST support is based on
>> JAX-WS, why we need the 'HTTP binding' to expose the JAX-WS service
>> again?
>>
>> Thanks,
>> James.
>>
>>> Author: dandiep
>>> Date: Mon Oct 23 11:52:16 2006
>>> New Revision: 467080
>>>
>>> URL: http://svn.apache.org/viewvc?view=rev&rev=467080
>>> Log:
>>> Add an "HTTP binding" which uses the Java Rest Annotations (new
>>> project at the
>>> Codehaus which James Strachan and I started) to expose JAX-WS
>>> services as REST style services.
>>> Thanks to Guillaume Nodet who supplied the IriDecoderHelper class
>>> which was
>>> indispensible.
>>>
>>> Currently this just includes:
>>> o simple server side functionality to take JAX-WS operations and
>>> expose them
>>> as resources using the @HttpResource annotation and
>>> @Get/@Put/@Post/@Delete.
>>> o Ability to take URI parameters and construct an incoming XML document
>>> according to WSDL 2 spec
>>> o Ability to take URI parameters and an incoming XML document and
>>> merge them
>>>
>>> Other things in this commit:
>>> o Fixed the JAXBDataBinding so we didn't twice initialize the Types
>>> if the WSDLServiceBuilder already did it.
>>> o Added support for recognizing unwrapped operations in
>>> XMLOutInterceptor
>>>
>>>
>>
>>
>
>
Re: About the REST/HTTP Binding... [was Re: svn commit: r467080 ...]
Posted by James Mao <ja...@iona.com>.
Hi Dan,
Thanks for your explanations, that make sense to me.
I review the code, and i wondering if the PUT should use addCustomer,
and the POST should use updateCustomer?
One thing i still can not understand is that the difference between REST
POST and the normal POST? are they same?
In @GET, how you map the uri to the operation name? through the
annotation? and i guess in @GET method we can only support simple type,
right?
What's the mechanism to map the uri to parameters? it's the name-value
pair or just value?
I'm thinking of support GET for SOAP1.2, but finally i found that it may
work for all bindings (SOAP1.1 SOAP1.2 and XML),
The scenario I'm imaging is that for the normal POST webservice, we can
use GET to retrieve the result through GET as long as the parameters are
simple type. sort of RPC style, but should work.
for example, for the hello_world sayHi/greetMe method, we normally write
a client code to invoke the service, since now we support GET, you don't
need to do so, you can even use browser to retrieve the result, just use
the URI http://localhost:9000/SoapContext/SoapPort/sayHi or
http://localhost:9000/SoapContext/SoapPort/greetMe/requestType/Dan or
http://localhost:9000/SoapContext/SoapPort/greetMe?requestType=Dan
Thoughts?
-James
> Hi James,
>
> While it could be called a REST binding, REST is an architectual
> style, not a specific implementation. When we talk about doing REST
> style services, usually we're talking about doing HTTP. HTTP is a
> protocol just like SOAP. We map operations to resources and http
> headers to parameters.
>
> One of the goals is to support the WSDL 2 HTTP binding [1] (which is
> part of where the name comes from too). While CXF has some basic
> XML/HTTP support it doesn't support the full range of things needed.
> For instance, I can't easily map URIs and verbs to operations. With
> the Java REST annotations which I've been working on, this is fairly
> trivial:
>
> @Get
> @HttpResource(location="/customers/{id}")
> public Customer getCustomer(String id) { .. }
>
> I can easily map an operation to any URI and also to any verb via
> @Get/@Post/@Delete/@Put.
>
> Does that help answer your questions?
>
> - Dan
>
> 1. http://www.w3.org/TR/wsdl20-adjuncts/#http-binding
> 2. http://jra.codehaus.org
>
> James Mao wrote:
>
>> Hi Dan,
>>
>> What's the 'HTTP binding' for? is it just for REST?
>> If so why call it 'HTTP binding'? can we call it 'REST binding'?
>> 'HTTP' sounds just like a transport.
>> The 'HTTP binding' is use HTTP transport, right? so we have 'HTTP
>> over HTTP'? sounds weird.
>>
>> Another question is that current CXF REST support is based on
>> JAX-WS, why we need the 'HTTP binding' to expose the JAX-WS service
>> again?
>>
>> Thanks,
>> James.
>>
>>> Author: dandiep
>>> Date: Mon Oct 23 11:52:16 2006
>>> New Revision: 467080
>>>
>>> URL: http://svn.apache.org/viewvc?view=rev&rev=467080
>>> Log:
>>> Add an "HTTP binding" which uses the Java Rest Annotations (new
>>> project at the
>>> Codehaus which James Strachan and I started) to expose JAX-WS
>>> services as REST style services.
>>> Thanks to Guillaume Nodet who supplied the IriDecoderHelper class
>>> which was
>>> indispensible.
>>>
>>> Currently this just includes:
>>> o simple server side functionality to take JAX-WS operations and
>>> expose them
>>> as resources using the @HttpResource annotation and
>>> @Get/@Put/@Post/@Delete.
>>> o Ability to take URI parameters and construct an incoming XML document
>>> according to WSDL 2 spec
>>> o Ability to take URI parameters and an incoming XML document and
>>> merge them
>>>
>>> Other things in this commit:
>>> o Fixed the JAXBDataBinding so we didn't twice initialize the Types
>>> if the WSDLServiceBuilder already did it.
>>> o Added support for recognizing unwrapped operations in
>>> XMLOutInterceptor
>>>
>>>
>>
>>
>
>
About the REST/HTTP Binding... [was Re: svn commit: r467080 ...]
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi James,
While it could be called a REST binding, REST is an architectual style,
not a specific implementation. When we talk about doing REST style
services, usually we're talking about doing HTTP. HTTP is a protocol
just like SOAP. We map operations to resources and http headers to
parameters.
One of the goals is to support the WSDL 2 HTTP binding [1] (which is
part of where the name comes from too). While CXF has some basic
XML/HTTP support it doesn't support the full range of things needed. For
instance, I can't easily map URIs and verbs to operations. With the Java
REST annotations which I've been working on, this is fairly trivial:
@Get
@HttpResource(location="/customers/{id}")
public Customer getCustomer(String id) { .. }
I can easily map an operation to any URI and also to any verb via
@Get/@Post/@Delete/@Put.
Does that help answer your questions?
- Dan
1. http://www.w3.org/TR/wsdl20-adjuncts/#http-binding
2. http://jra.codehaus.org
James Mao wrote:
> Hi Dan,
>
> What's the 'HTTP binding' for? is it just for REST?
> If so why call it 'HTTP binding'? can we call it 'REST binding'?
> 'HTTP' sounds just like a transport.
> The 'HTTP binding' is use HTTP transport, right? so we have 'HTTP over
> HTTP'? sounds weird.
>
> Another question is that current CXF REST support is based on
> JAX-WS, why we need the 'HTTP binding' to expose the JAX-WS service
> again?
>
> Thanks,
> James.
>
>> Author: dandiep
>> Date: Mon Oct 23 11:52:16 2006
>> New Revision: 467080
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=467080
>> Log:
>> Add an "HTTP binding" which uses the Java Rest Annotations (new
>> project at the
>> Codehaus which James Strachan and I started) to expose JAX-WS
>> services as REST style services.
>> Thanks to Guillaume Nodet who supplied the IriDecoderHelper class
>> which was
>> indispensible.
>>
>> Currently this just includes:
>> o simple server side functionality to take JAX-WS operations and
>> expose them
>> as resources using the @HttpResource annotation and
>> @Get/@Put/@Post/@Delete.
>> o Ability to take URI parameters and construct an incoming XML document
>> according to WSDL 2 spec
>> o Ability to take URI parameters and an incoming XML document and
>> merge them
>>
>> Other things in this commit:
>> o Fixed the JAXBDataBinding so we didn't twice initialize the Types
>> if the WSDLServiceBuilder already did it.
>> o Added support for recognizing unwrapped operations in
>> XMLOutInterceptor
>>
>>
>
>
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com