For a provider based RESTful service, i think that's it.
And what i really want to see is that our RESTful client can consume big
REST player, like amazon.
It'll be amazing that we put a demo to show how cxf RESTful client can
consume the service provided by amazon.
And also our RESTful service should be able to be consumed by other
RESTful client.
Cheers,
James.
Liu, Jervis 写道:
Hi Brandon,
Thanks for the reply. I wont be so sure that HTTP POST should be mapped to an INSERT. As you mentioned, what spec says about POST is "process this" and GET is "set the state of the resource to this". My interpretation tends to be same as [1], i.e., POST maps to update and PUT maps to Creat. But anyway, I guess this again is a controversial topic. The good thing of using JAX-WS provider as the first step to produce a RESTful demo is that this avoids the debate and it is up to the user's logic (in Provider.invoke()) to decide how to interpret.
[1]. http://java.sun.com/developer/technicalArticles/WebServices/restful/
Cheers,
Jervis
-----Original Message-----
From: Brandon Smith [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 20, 2006 8:24 PM
To: [email protected]
Subject: Re: RESTful demo for review
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 <[EMAIL PROTECTED]> 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
