axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <>
Subject Re: [Axis2] Motivation of RESTful web services support
Date Tue, 05 Sep 2006 01:57:51 GMT
On Mon, 2006-09-04 at 13:30 +0800, Xinjun Chen wrote:
> It is very exciting to see you expert with different ideas discussing
> the issues here :-).
> I have some misconception about REST. I had thought only POST can be
> used if there are some parameter info to transmit. In fact, I am still
> not quite sure how to transmit parameter info if GET is used. Say, if
> "void operationA(ComplexTypeA complexVar)" is the signature, how can I
> pass in the complexTypeA info if using GET?

In theory you can do anything in a URI .. its like an infinitely long
Turing tape ;-). So in theory you can take *any* data and URI encode it
and stick it as a parameter (or a path component) of a GET.

However, in practice there's a 4k limit and no one in their right mind
would even test that. So often people off GET bindings for stuff that
has simple data coming in ... and that's what the WSDL 2.0 spec also
supports very elegantly (you should look at it as that'll explain the
Axis2 design point). 

> I am not sure whether I am asking the correct question. Am I trying to
> understand REST using a service-oriented view when asking this
> question?

IMO Yes; if you're using REST you use GET if the act of getting a
representation of the resource is "safe"; i.e., side-effect free. How
you identify the resource (with a complex path, with query params) is
not relevant in theory.

Another thing to understand is the SOAP 1.2 SOAP Response MEP - that
basically defines a mapping for an HTTP GET to SOAP response pattern.
Again that too is nicely supported by Axis2.

So the real thing with REST is not how you can stuff a bunch of stuff
into a URI .. rather about what your resources are and whether you can
map all the interactions to the actions of GETting representation of the
resource, PUTting a representation of the resource, POSTing some data to
a resource, and DELETEing a resource. Of course GETting a representation
of the resource shouldn't "change" the resource.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message