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
