You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "Liu, Jervis" <jl...@iona.com> on 2006/09/20 12:23:28 UTC
RESTful demo for review
Hi,
Based on the REST discussion we had before in this mailing list, I have created an initial version of RESTful demo ( http://svn.apache.org/viewvc?view=rev <http://svn.apache.org/viewvc?view=rev&rev=448148> &rev=448148). The intention is to show how to publish/consume RESTful services using the programming models offered by CXF, for the time being, the primary focus is demonstrating the REST based webservices using XML binding and JAX-WS Provider/Dispatch. When CXF grows, we can add more RESTful capabilities into CXF, for example, serving REST service using Spring POJO etc. Please note the current effort is by no means to invent a "real" REST programming model.
The RESTful communication scenarios covered by this demo are as below:
A RESTful customer service is provided on URL http://localhost:9000/customerservice/customers, users access this URI to query or update customer info.
A HTTP GET request to URL <http://localhost:9000/customerservice/customers> http://localhost:9000/customerservice/customers returns a list of customer hyperlinks, this allows client navigates through the application states. The xml document returned:
<Customers>
<Customer href=" <http://localhost/customerservice/customer?id=1234> http://localhost/customerservice/customer?id=1234">
<id>1234</id>
</Customer>
<Customer href=" <http://localhost/customerservice/customer?id=1235> http://localhost/customerservice/customer?id=1235">
<id>1235</id>
</Customer>
<Customer href=" <http://localhost/customerservice/customer?id=1236> http://localhost/customerservice/customer?id=1236">
<id>1236</id>
</Customer>
</Customers>
A HTTP GET request to URL <http://localhost:9000/customerservice/customers?id=1234> http://localhost:9000/customerservice/customers?id=1234 returns a customer instance whose id is 1234. The xml document returned:
<Customer>
<id>1234</id>
<name>John</name>
<phoneNumber>123456</phoneNumber>
</Customer>
A HTTP POST request to URL <http://localhost:9000/customerservice/customers> http://localhost:9000/customerservice/customers with data:
<Customer>
<id>1234</id>
<name>John</name>
<phoneNumber>234567</phoneNumber>
</Customer>
updates customer 1234 with the data provided.
The demo client side codes demonstrate how to sent HTTP POST with XML data using JAX-WS dispatch and how to sent HTTP GET using URL.openStream().
There are some immediate improvements we can make to this demo:
1. Remove the presence of WSDL files from both server and client side: REST does not need WSDL file. JAX-WS provider/dispatch does not need WSDL too. However our current implementation of provider/dispatch can not work without wsdl, that's why you can see wsdl files in this RESTful demo. This needs to be fixed
2. Support sending HTTP GET using JAX-WS dispatch: A HTTP GET request can be sent by using URL.openStream or by using JAX-WS dispatch. Though I do not see much benefit of using the latter, we do need to support it. According to JAX-WS spec, this can be done by adding extra non-standard properties into request context. A code snippet may look like below:
Service service = Service.createService();
service.addPort(portQName, " <http://cxf.apache.org/bindings/xformat> http://cxf.apache.org/bindings/xformat", endpointAddress);
Dispatch<Source> d = service.createDispatch(portQName, Source.class, Service.Mode.PAYLOAD);
Map<String, Object> requestContext = d.getRequestContext();
requestContext.put(Message.HTTP_REQUEST_METHOD, new String("GET"));
requestContext.put(Message.QUERY_STRING, queryString);
requestContext.put(Message.PATH_INFO, path);
Source result = d.invoke(null);
Does this look alright to everybody?
Moving forward, I also want to see following things being discussed:
1. How to expose an existing Web Service as a RESTful service. Say, I have an existing Web Service written in JAX-WS, it would be really great if CXF can help me to publish it as a RESTful service with minimal changes. In this case, I see the need to support SEI on both server and client side. Several issues involved:
c. We will need a REST binding. This REST binding does have WSDL file. We can have a wsdltorest tool to help generating the WSDL binding part for REST binding. Probably this is the only thing users need to do to port an existing web service to REST.
a. How to map between REST resources and service operations. The easiest approach is using fixed method names for the REST operations. I.e., given a base URI context like <http://localhost/foo> http://localhost/foo (this is the http:address in the wsdl file), a SEI method sayHi is mapped to URL <http://localhost/foo/sayHi> http://localhost/foo/sayHi. Based on our previous discussion, this does not conform to REST semantics very well. But one could argue that the traditional applications are not REST anyway, we just make it serving services with more REST flavors.
b. We need a method dispatch and parameter marshal/unmarshall mechanism different from JAX-WS. For HTTP POST, the data sent on the wire should be a raw xml , it is the URL who indicates the method being requested. The xml data itself still needs to conform to xml schema in WSDL. For HTTP GET, we need encode/decode method name and parameters into URL.
Anyway, this story seems need a bit work to do. I see this as a valid requirement but I am not very sure the above is the right way to approach. FYI, Axis2 does support publishing existing SOAP service as REST service, but it is a pure hack to me. <http://people.apache.org/%7Esamisa/ApacheCon_EU_2006_REST.ppt> http://people.apache.org/%7Esamisa/ApacheCon_EU_2006_REST.ppt
2. As Steve pointed out before, how to better support navigation of application state via hyperlinks. "CXF has to enable and perhaps help the server-side application to generate the URLs required to identify new resources that it creates and tie servants/ implementations to them. Applications have to play their part, too, by following the semantics of HTTP, such as ensuring that GETs are idempotent, and ensuring that the URLs it produces for its resources and state aren't just always temporary or transient."
3. Look into WSDL2's HTTP support to see what we can leverage from there.
Thoughts and comments?
Thanks,
Jervis
Re: RESTful demo for review
Posted by Brandon Smith <br...@16cards.com>.
There is a lot of debate in various communities on when to use POST
vs. PUT because the HTTP spec is not as direct with the POST method as
it is the other methods. The spec basically says POST means "process
this request."
It seems the general concensus out there is that a POST on a
"collection" URI maps to an INSERT operation. The examples provided
should then be:
THE GET/RETRIEVE/SELECT OPERATION:
The reqeust:
GET /customerservice/customers?id=1234 HTTP/1.1
Host: localhost:9000
The response:
HTTP/1.1 200 OK
...[other headers]...
<Customer>
<id>1234</id>
<name>John</name>
<phoneNumber>123456</phoneNumber>
</Customer>
The result:
Returns an XML document representing the customer entity whose
identifier is 1234.
THE POST/CREATE/INSERT OPERATION:
The request:
POST /customerservice/customers HTTP/1.1
Host: localhost:9000
Content-Type: application/xml
Content-Length: [length]
<Customer>
<id>1234</id>
<name>John</name>
<phoneNumber>234567</phoneNumber>
</Customer>
The response:
HTTP/1.1 201 CREATED
...[other headers]...
The result:
Inserts a customer 1234 with the XML data representation provided into
the collection.
THE PUT/UPDATE OPERATION:
The request:
PUT /customerservice/customers?id=1234 HTTP/1.1
Host: localhost:9000
Content-Type: application/xml
Content-Length: [length]
<Customer>
<id>1234</id>
<name>John</name>
<phoneNumber>234567</phoneNumber>
</Customer>
The response:
HTTP/1.1 200 OK
...[other headers]...
The result:
Updates a customer 1234 with the XML data representation provided.
THE DELETE OPERATION:
The request:
DELETE /customerservice/customers?id=1234 HTTP/1.1
Host: localhost:9000
The response:
HTTP/1.1 200 OK
...[other headers]...
The result:
Customer entity with identifier 1234 is removed from the collection.
On 9/20/06, Liu, Jervis <jl...@iona.com> wrote:
> Hi,
>
> Based on the REST discussion we had before in this mailing list, I have created an initial version of RESTful demo ( http://svn.apache.org/viewvc?view=rev <http://svn.apache.org/viewvc?view=rev&rev=448148> &rev=448148). The intention is to show how to publish/consume RESTful services using the programming models offered by CXF, for the time being, the primary focus is demonstrating the REST based webservices using XML binding and JAX-WS Provider/Dispatch. When CXF grows, we can add more RESTful capabilities into CXF, for example, serving REST service using Spring POJO etc. Please note the current effort is by no means to invent a "real" REST programming model.
>
> The RESTful communication scenarios covered by this demo are as below:
>
> A RESTful customer service is provided on URL http://localhost:9000/customerservice/customers, users access this URI to query or update customer info.
>
> A HTTP GET request to URL <http://localhost:9000/customerservice/customers> http://localhost:9000/customerservice/customers returns a list of customer hyperlinks, this allows client navigates through the application states. The xml document returned:
>
> <Customers>
> <Customer href=" <http://localhost/customerservice/customer?id=1234> http://localhost/customerservice/customer?id=1234">
> <id>1234</id>
> </Customer>
> <Customer href=" <http://localhost/customerservice/customer?id=1235> http://localhost/customerservice/customer?id=1235">
> <id>1235</id>
> </Customer>
> <Customer href=" <http://localhost/customerservice/customer?id=1236> http://localhost/customerservice/customer?id=1236">
> <id>1236</id>
> </Customer>
> </Customers>
>
> A HTTP GET request to URL <http://localhost:9000/customerservice/customers?id=1234> http://localhost:9000/customerservice/customers?id=1234 returns a customer instance whose id is 1234. The xml document returned:
>
> <Customer>
> <id>1234</id>
> <name>John</name>
> <phoneNumber>123456</phoneNumber>
> </Customer>
>
> A HTTP POST request to URL <http://localhost:9000/customerservice/customers> http://localhost:9000/customerservice/customers with data:
>
> <Customer>
> <id>1234</id>
> <name>John</name>
> <phoneNumber>234567</phoneNumber>
> </Customer>
>
> updates customer 1234 with the data provided.
>
> The demo client side codes demonstrate how to sent HTTP POST with XML data using JAX-WS dispatch and how to sent HTTP GET using URL.openStream().
>
> There are some immediate improvements we can make to this demo:
>
> 1. Remove the presence of WSDL files from both server and client side: REST does not need WSDL file. JAX-WS provider/dispatch does not need WSDL too. However our current implementation of provider/dispatch can not work without wsdl, that's why you can see wsdl files in this RESTful demo. This needs to be fixed
>
> 2. Support sending HTTP GET using JAX-WS dispatch: A HTTP GET request can be sent by using URL.openStream or by using JAX-WS dispatch. Though I do not see much benefit of using the latter, we do need to support it. According to JAX-WS spec, this can be done by adding extra non-standard properties into request context. A code snippet may look like below:
>
> Service service = Service.createService();
> service.addPort(portQName, " <http://cxf.apache.org/bindings/xformat> http://cxf.apache.org/bindings/xformat", endpointAddress);
> Dispatch<Source> d = service.createDispatch(portQName, Source.class, Service.Mode.PAYLOAD);
>
> Map<String, Object> requestContext = d.getRequestContext();
> requestContext.put(Message.HTTP_REQUEST_METHOD, new String("GET"));
> requestContext.put(Message.QUERY_STRING, queryString);
> requestContext.put(Message.PATH_INFO, path);
>
> Source result = d.invoke(null);
>
> Does this look alright to everybody?
>
> Moving forward, I also want to see following things being discussed:
>
> 1. How to expose an existing Web Service as a RESTful service. Say, I have an existing Web Service written in JAX-WS, it would be really great if CXF can help me to publish it as a RESTful service with minimal changes. In this case, I see the need to support SEI on both server and client side. Several issues involved:
>
> c. We will need a REST binding. This REST binding does have WSDL file. We can have a wsdltorest tool to help generating the WSDL binding part for REST binding. Probably this is the only thing users need to do to port an existing web service to REST.
>
> a. How to map between REST resources and service operations. The easiest approach is using fixed method names for the REST operations. I.e., given a base URI context like <http://localhost/foo> http://localhost/foo (this is the http:address in the wsdl file), a SEI method sayHi is mapped to URL <http://localhost/foo/sayHi> http://localhost/foo/sayHi. Based on our previous discussion, this does not conform to REST semantics very well. But one could argue that the traditional applications are not REST anyway, we just make it serving services with more REST flavors.
>
> b. We need a method dispatch and parameter marshal/unmarshall mechanism different from JAX-WS. For HTTP POST, the data sent on the wire should be a raw xml , it is the URL who indicates the method being requested. The xml data itself still needs to conform to xml schema in WSDL. For HTTP GET, we need encode/decode method name and parameters into URL.
>
> Anyway, this story seems need a bit work to do. I see this as a valid requirement but I am not very sure the above is the right way to approach. FYI, Axis2 does support publishing existing SOAP service as REST service, but it is a pure hack to me. <http://people.apache.org/%7Esamisa/ApacheCon_EU_2006_REST.ppt> http://people.apache.org/%7Esamisa/ApacheCon_EU_2006_REST.ppt
>
> 2. As Steve pointed out before, how to better support navigation of application state via hyperlinks. "CXF has to enable and perhaps help the server-side application to generate the URLs required to identify new resources that it creates and tie servants/ implementations to them. Applications have to play their part, too, by following the semantics of HTTP, such as ensuring that GETs are idempotent, and ensuring that the URLs it produces for its resources and state aren't just always temporary or transient."
>
> 3. Look into WSDL2's HTTP support to see what we can leverage from there.
>
>
>
> Thoughts and comments?
>
> Thanks,
> Jervis
>
>
>
>
>
>
>
>
Re: RESTful demo for review
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Jervis
<Customers>
<Customer href="http://localhost/customerservice/customer?id=1234> <id>1234</id>
</Customer>
<!-- more customers -->
</Customers>
Just a minor comment here. I think it would be more descriptiove if some info more meaningful than an id (when available) can be
returned to a client as part of collection queries, perhaps a name, or something similar. With ids you dont get anything interesting
out of the collection, nothing to look at for a (human) user. If we have :
<Customers>
<Customer href="http://localhost/customerservice/customer?id=1234> <name>John</name>
</Customer>
<!-- more customers -->
</Customers>
Not a lot of interesting info, but still a client can use a name in order to choose which reference to follow, etc...
Perhaps for this to work two annotations should be made, one for identifying a field which will be used as part of href, another one
for identifying the ref value like 'John'.
Another thing is that it might be worth considering identifying reference-like elements as being references :
<CustomerRef href="http://localhost/customerservice/customer?id=1234> <name>John</name>
</CustomerRef>
It makes it easier to understand that a collection returns a bunch of references. The thing is is that most likely there'll be a
schema out there which says how a Customer instance may look like and it may not permit Customer instances not to contain all
elements or to contain an href attribute. Perhaps the convention should be <BeanName>+"Ref" for naming references. xml.com hosts a
lot of interesting articles about it...
"There are some immediate improvements we can make to this demo:
1. Remove the presence of WSDL files from both server and client side: REST does not need WSDL file."
I really would like yourself/us to think more about it. WSDL is often displayed now as something that just blocks the evolution. It
may or may not be the case. The power is not in the ability to invoke operations on the stubs but on the xml data type system WSDL
relies upon. With a proper design one might get both a perceived convinience of stubs and the extensibility coming from xml schema
languages...
I agree REST does not need WSDL and I also agree with both yourself and Dan that WSDL2 HTTP/XML support will be good to have.
The main power of something like WSDL, as far as REST is concerned is about client-side tooling. This is one of the key things IMHO
for CXF to consider as far as its REST support is concerned. WSDL 2.0 is good but it;'s not as good as WADL promises to be in terms
of facilitating client-side usage of hyperlink references.
As I said I agree REST does not need WSDL. But the thing is that we'd probably like clinets to use CXF too.
What is interesting about REST is that it's really about the client, the focus is on the client so that it can be adaptable to
changes. If it all can be facilitated by a good client-side tooling then it'd make it much easier for people to start experimenting
with REST using *CXF* on both sides :-)
Cheers, Sergey
Hi,
Based on the REST discussion we had before in this mailing list, I have created an initial version of RESTful demo (
http://svn.apache.org/viewvc?view=rev <http://svn.apache.org/viewvc?view=rev&rev=448148> &rev=448148). The intention is to show how
to publish/consume RESTful services using the programming models offered by CXF, for the time being, the primary focus is
demonstrating the REST based webservices using XML binding and JAX-WS Provider/Dispatch. When CXF grows, we can add more RESTful
capabilities into CXF, for example, serving REST service using Spring POJO etc. Please note the current effort is by no means to
invent a "real" REST programming model.
The RESTful communication scenarios covered by this demo are as below:
A RESTful customer service is provided on URL http://localhost:9000/customerservice/customers, users access this URI to query or
update customer info.
A HTTP GET request to URL <http://localhost:9000/customerservice/customers> http://localhost:9000/customerservice/customers returns
a list of customer hyperlinks, this allows client navigates through the application states. The xml document returned:
<Customers>
<Customer href=" <http://localhost/customerservice/customer?id=1234> http://localhost/customerservice/customer?id=1234">
<id>1234</id>
</Customer>
<Customer href=" <http://localhost/customerservice/customer?id=1235> http://localhost/customerservice/customer?id=1235">
<id>1235</id>
</Customer>
<Customer href=" <http://localhost/customerservice/customer?id=1236> http://localhost/customerservice/customer?id=1236">
<id>1236</id>
</Customer>
</Customers>
A HTTP GET request to URL <http://localhost:9000/customerservice/customers?id=1234>
http://localhost:9000/customerservice/customers?id=1234 returns a customer instance whose id is 1234. The xml document returned:
<Customer>
<id>1234</id>
<name>John</name>
<phoneNumber>123456</phoneNumber>
</Customer>
A HTTP POST request to URL <http://localhost:9000/customerservice/customers> http://localhost:9000/customerservice/customers with
data:
<Customer>
<id>1234</id>
<name>John</name>
<phoneNumber>234567</phoneNumber>
</Customer>
updates customer 1234 with the data provided.
The demo client side codes demonstrate how to sent HTTP POST with XML data using JAX-WS dispatch and how to sent HTTP GET using
URL.openStream().
There are some immediate improvements we can make to this demo:
1. Remove the presence of WSDL files from both server and client side: REST does not need WSDL file. JAX-WS provider/dispatch does
not need WSDL too. However our current implementation of provider/dispatch can not work without wsdl, that's why you can see wsdl
files in this RESTful demo. This needs to be fixed
2. Support sending HTTP GET using JAX-WS dispatch: A HTTP GET request can be sent by using URL.openStream or by using JAX-WS
dispatch. Though I do not see much benefit of using the latter, we do need to support it. According to JAX-WS spec, this can be done
by adding extra non-standard properties into request context. A code snippet may look like below:
Service service = Service.createService();
service.addPort(portQName, " <http://cxf.apache.org/bindings/xformat> http://cxf.apache.org/bindings/xformat",
endpointAddress);
Dispatch<Source> d = service.createDispatch(portQName, Source.class, Service.Mode.PAYLOAD);
Map<String, Object> requestContext = d.getRequestContext();
requestContext.put(Message.HTTP_REQUEST_METHOD, new String("GET"));
requestContext.put(Message.QUERY_STRING, queryString);
requestContext.put(Message.PATH_INFO, path);
Source result = d.invoke(null);
Does this look alright to everybody?
Moving forward, I also want to see following things being discussed:
1. How to expose an existing Web Service as a RESTful service. Say, I have an existing Web Service written in JAX-WS, it would be
really great if CXF can help me to publish it as a RESTful service with minimal changes. In this case, I see the need to support SEI
on both server and client side. Several issues involved:
c. We will need a REST binding. This REST binding does have WSDL file. We can have a wsdltorest tool to help generating the WSDL
binding part for REST binding. Probably this is the only thing users need to do to port an existing web service to REST.
a. How to map between REST resources and service operations. The easiest approach is using fixed method names for the REST
operations. I.e., given a base URI context like <http://localhost/foo> http://localhost/foo (this is the http:address in the wsdl
file), a SEI method sayHi is mapped to URL <http://localhost/foo/sayHi> http://localhost/foo/sayHi. Based on our previous
discussion, this does not conform to REST semantics very well. But one could argue that the traditional applications are not REST
anyway, we just make it serving services with more REST flavors.
b. We need a method dispatch and parameter marshal/unmarshall mechanism different from JAX-WS. For HTTP POST, the data sent on the
wire should be a raw xml , it is the URL who indicates the method being requested. The xml data itself still needs to conform to xml
schema in WSDL. For HTTP GET, we need encode/decode method name and parameters into URL.
Anyway, this story seems need a bit work to do. I see this as a valid requirement but I am not very sure the above is the right way
to approach. FYI, Axis2 does support publishing existing SOAP service as REST service, but it is a pure hack to me.
<http://people.apache.org/%7Esamisa/ApacheCon_EU_2006_REST.ppt> http://people.apache.org/%7Esamisa/ApacheCon_EU_2006_REST.ppt
2. As Steve pointed out before, how to better support navigation of application state via hyperlinks. "CXF has to enable and perhaps
help the server-side application to generate the URLs required to identify new resources that it creates and tie servants/
implementations to them. Applications have to play their part, too, by following the semantics of HTTP, such as ensuring that GETs
are idempotent, and ensuring that the URLs it produces for its resources and state aren't just always temporary or transient."
3. Look into WSDL2's HTTP support to see what we can leverage from there.
Thoughts and comments?
Thanks,
Jervis
Re: RESTful demo for review
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hi Jervis,
Liu, Jervis wrote:
>Hi,
>
>Based on the REST discussion we had before in this mailing list, I have created an initial version of RESTful demo ( http://svn.apache.org/viewvc?view=rev <http://svn.apache.org/viewvc?view=rev&rev=448148> &rev=448148). The intention is to show how to publish/consume RESTful services using the programming models offered by CXF, for the time being, the primary focus is demonstrating the REST based webservices using XML binding and JAX-WS Provider/Dispatch. When CXF grows, we can add more RESTful capabilities into CXF, for example, serving REST service using Spring POJO etc. Please note the current effort is by no means to invent a "real" REST programming model.
>
>The RESTful communication scenarios covered by this demo are as below:
>
>A RESTful customer service is provided on URL http://localhost:9000/customerservice/customers, users access this URI to query or update customer info.
>
>A HTTP GET request to URL <http://localhost:9000/customerservice/customers> http://localhost:9000/customerservice/customers returns a list of customer hyperlinks, this allows client navigates through the application states. The xml document returned:
>
><Customers>
> <Customer href=" <http://localhost/customerservice/customer?id=1234> http://localhost/customerservice/customer?id=1234">
> <id>1234</id>
> </Customer>
> <Customer href=" <http://localhost/customerservice/customer?id=1235> http://localhost/customerservice/customer?id=1235">
> <id>1235</id>
> </Customer>
> <Customer href=" <http://localhost/customerservice/customer?id=1236> http://localhost/customerservice/customer?id=1236">
> <id>1236</id>
> </Customer>
></Customers>
>
>A HTTP GET request to URL <http://localhost:9000/customerservice/customers?id=1234> http://localhost:9000/customerservice/customers?id=1234 returns a customer instance whose id is 1234. The xml document returned:
>
><Customer>
> <id>1234</id>
> <name>John</name>
> <phoneNumber>123456</phoneNumber>
></Customer>
>
>A HTTP POST request to URL <http://localhost:9000/customerservice/customers> http://localhost:9000/customerservice/customers with data:
>
><Customer>
> <id>1234</id>
> <name>John</name>
> <phoneNumber>234567</phoneNumber>
></Customer>
>
>updates customer 1234 with the data provided.
>
>The demo client side codes demonstrate how to sent HTTP POST with XML data using JAX-WS dispatch and how to sent HTTP GET using URL.openStream().
>
>
>
This is OK, but I don't see how this really gets anyone anything over
writing their own using URLs and sources without the JAX-WS stuff.
>There are some immediate improvements we can make to this demo:
>
>1. Remove the presence of WSDL files from both server and client side: REST does not need WSDL file. JAX-WS provider/dispatch does not need WSDL too. However our current implementation of provider/dispatch can not work without wsdl, that's why you can see wsdl files in this RESTful demo. This needs to be fixed
>
>
I would definitely like to support the WSDL 2 HTTP/REST stuff though,
its pretty cool.
>
>2. Support sending HTTP GET using JAX-WS dispatch: A HTTP GET request can be sent by using URL.openStream or by using JAX-WS dispatch. Though I do not see much benefit of using the latter, we do need to support it. According to JAX-WS spec, this can be done by adding extra non-standard properties into request context. A code snippet may look like below:
>
> Service service = Service.createService();
> service.addPort(portQName, " <http://cxf.apache.org/bindings/xformat> http://cxf.apache.org/bindings/xformat", endpointAddress);
> Dispatch<Source> d = service.createDispatch(portQName, Source.class, Service.Mode.PAYLOAD);
>
> Map<String, Object> requestContext = d.getRequestContext();
> requestContext.put(Message.HTTP_REQUEST_METHOD, new String("GET"));
> requestContext.put(Message.QUERY_STRING, queryString);
> requestContext.put(Message.PATH_INFO, path);
>
> Source result = d.invoke(null);
>
>Does this look alright to everybody?
>
>Moving forward, I also want to see following things being discussed:
>
>1. How to expose an existing Web Service as a RESTful service. Say, I have an existing Web Service written in JAX-WS, it would be really great if CXF can help me to publish it as a RESTful service with minimal changes. In this case, I see the need to support SEI on both server and client side. Several issues involved:
>
>c. We will need a REST binding. This REST binding does have WSDL file. We can have a wsdltorest tool to help generating the WSDL binding part for REST binding. Probably this is the only thing users need to do to port an existing web service to REST.
>
>a. How to map between REST resources and service operations. The easiest approach is using fixed method names for the REST operations. I.e., given a base URI context like <http://localhost/foo> http://localhost/foo (this is the http:address in the wsdl file), a SEI method sayHi is mapped to URL <http://localhost/foo/sayHi> http://localhost/foo/sayHi. Based on our previous discussion, this does not conform to REST semantics very well. But one could argue that the traditional applications are not REST anyway, we just make it serving services with more REST flavors.
>
>
>
So I was chatting with James Strachan a bit at Javazone and we came up
with a little set of java rest annotations. Two ways it could be put
together.
1. The JAX-WS way
@WebService
public interface CustomerService {
@Get
@Rest(uri="/customers")
public List<Customer> getCustomers();
@Get
@Rest(uri="/customers/{id}")
public Customer getCustomer(string id);
@Post
@Rest(uri="/customers/{id}")
public void updateCustomer(Customer c);
... etc
}
2. The Bean way
@Rest(uri="/customers/{id}")
public class CustomerService {
private String id;
public Customer get();
@Post
pulblic void update(Customer c);
}
In this case "id" gets injected. Also, the @Post/Get/Put annotations get
used if the method name doesn't follow convention.
The @Rest annotation would support both the uri field and
queryParameters So this annotation @Rest(uri="/customers",
queryParmaters=new String[] { "id" }) would use an id query parameter
instead of putting the id in the URI (i.e. /customers?id=123)
We would also want to support an XML version of the annotations so we
could map things to multiple URIs.
>b. We need a method dispatch and parameter marshal/unmarshall mechanism different from JAX-WS. For HTTP POST, the data sent on the wire should be a raw xml , it is the URL who indicates the method being requested. The xml data itself still needs to conform to xml schema in WSDL. For HTTP GET, we need encode/decode method name and parameters into URL.
>
>Anyway, this story seems need a bit work to do. I see this as a valid requirement but I am not very sure the above is the right way to approach. FYI, Axis2 does support publishing existing SOAP service as REST service, but it is a pure hack to me. <http://people.apache.org/%7Esamisa/ApacheCon_EU_2006_REST.ppt> http://people.apache.org/%7Esamisa/ApacheCon_EU_2006_REST.ppt
>
>
Yeah, their REST stuff is VERY ugly.
>
>2. As Steve pointed out before, how to better support navigation of application state via hyperlinks. "CXF has to enable and perhaps help the server-side application to generate the URLs required to identify new resources that it creates and tie servants/ implementations to them. Applications have to play their part, too, by following the semantics of HTTP, such as ensuring that GETs are idempotent, and ensuring that the URLs it produces for its resources and state aren't just always temporary or transient."
>
>3. Look into WSDL2's HTTP support to see what we can leverage from there.
>
>
+1
- Dan
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com