Axis2: This Ain't REST
This Ain't REST
I have been playing around with Axis2 to create some sample services for the Taverna people to chew on when I looked closer at the "REST support"....
Running the Client
==================
- From your browser, If you point to the following URL:
http://localhost:8080/axis2/rest/StockQuoteService/getPrice?symbol=IBM
You will get the following response:
42.0
- If you invoke the update method like so:
http://localhost:8080/axis2/rest/StockQuoteService/update?symbol=IBM&price=100
And then execute the first getPrice url. You can see that the price got updated.
So you use GET to update the price! I think not. GET is safe, it should have no
side effects. This is bad because it is a toolkit advocating an approach, and
to think that it comes from the Apache foundation.
I have been playing around with Axis2 to create some sample services for the Taverna people to chew on when I looked closer at the "REST support"....
Running the Client
==================
- From your browser, If you point to the following URL:
http://localhost:8080/axis2/rest/StockQuoteService/getPrice?symbol=IBM
You will get the following response:
- If you invoke the update method like so:
http://localhost:8080/axis2/rest/StockQuoteService/update?symbol=IBM&price=100
And then execute the first getPrice url. You can see that the price got updated.
So you use GET to update the price! I think not. GET is safe, it should have no
side effects. This is bad because it is a toolkit advocating an approach, and
to think that it comes from the Apache foundation.
posted by Mark Mc Keown at 8:56 AM
3 Comments:
You are quite right. This feature has been incorrectly labelled REST when it is not. It is really a POX/HTTP (Plain Ole XML) solution.
Adding real resource support to Axis2 is in some people's minds, but currently Axis2 is very Service oriented not Resource oriented.
That said, this is actually a *useful* feature of Axis2, and if you only use a subset of it then it won't break REST.
Paul
You're right. The Axis2 1.1 documentation on REST is totally misleading. In addition, they use a URI such as http://127.0.0.1:8080/axis2/rest/version/getVersion as an example to obtain a version number. It doesn't really matter (after all, URIs are supposed to be opaque), but it shows that they've missed the point (i.e. something like this would have been enough: http://127.0.0.1:8080/axis2/rest/version).
Paul - I am afraid it is not POX/HTTP either, because it breaks HTTP, see
Section 9.1.1 of the HTTP spec.
"In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested."
The problems occur with things like Google Web Accelerator, it works with your browser to improve the browser experience, for example by pre-fetching links on a page. Now point this at a Tomcat configuration Web page :-(
Reusing some standard form of "get" (WS-RF, WS-Transfer etc) is better than writing lots of gets. However, HTTP GET can support content negotiation, Conditional-GETs, caching, mobile code, redirection as well as being safe and idempotent. These are some of the advantages REST has as an approach to distributed computing over WS-* for certain types of problems; REST is designed to applied to one set of problems, but is not applicable to all.
Whether writing a REST or a WS-* framework is eashier is a different question, to whether one is a better approach to building distributed systems. A good REST framework would make it easy to support caching, Conditional-GET,re-direction, mobile code (AJAX) and content negotiation.
cheers
Mark
Post a Comment
<< Home