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 Sat, 02 Sep 2006 06:36:56 GMT
On Thu, 2006-08-31 at 17:30 +0800, Xinjun Chen wrote:
> Hi,
> I read through the Axis2 documentation about RESTful support from
> I have some questions here.
> 1. What's the motivation of RESTful web services support in Axis2? If
> the efficiency the main motivation of REST spport?

The motivation is to support the HTTP binding in WSDL 2.0. What that
allows is for a service to have both SOAP and HTTP bindings- the service
impl deals with processing the service data (represented as an XML
element in WSDL 2.0) and whether the data arrives in a SOAP envelope,
inside an HTTP POST or as an HTTP GET. We support that in the client
side as well in the opposite direction: client sends off some XML and
depending on the binding it goes inside a SOAP envelope, in the body of
an HTTP POST or in the URL.

So we do more than "POX" as Anne described: its POX + also URLs being
used to invoke services. 

As Anne said in her replies, not everyone needs all the "enterprisey"
features of SOAP .. what Axis2 allows is for service authors and clients
to just deal with the payload and allow the middleware (Axis2) to deal
with it.

> 2. If the client send a request in a RESTful way, will there be no
> SOAP headers on the wire? Does this improve efficiency?

It does if you consider the payload size. However, efficiency increase
is minimal- a SOAP envelope with no headers is just two wrapper elements
that are wasted over POX.

> 3. Since there is no SOAP headers, does it mean some features like
> WS-Addressing support, WS-Security, and implementations of other Web
> services specifications which depends on SOAP headers will be
> automatically disabled? 


> Will REST be really useful in business and
> industry without security? 

HTTPS and HTTP authentication provides a level of security which is
sufficient for many applications. It is not sufficient for the "Web of
trust" level that is now evolving with certificates and such and it is
not sufficient to support message level security (i.e., HTTP security
ends when the payload is delivered). There are many cases where that
level of security is sufficient but there are many cases where that's
absolutely not sufficient and the full WS-* stack including WS-Security,
WS-Trust, WS-Reliable Messaging etc. is all critically needed.

With Axis2 the service author and service client don't have to directly
deal with any of this stuff- you deal with just the payload and policy
assertions are used to engage additional features like WS-Security.

> Without the WS-Addressing, can we still
> have another way to build and invoke stateful web services?

If you buy the REST religion there is no such thing .. in fact even
cookies violate the REST principles. However, people do use HTTP cookies
for lots and lots of things .. so the same is possible here with REST
style services: you can have sessions which are associated to the
transport via cookies. So you can have "stateful" interactions with

> 4. Why there is separation of SOAP web services and REST web services?
> >From the explanation in the link, it seems that even if the client
> invoke the web services in a RESTful way, at the server side, the
> Axis2 engine still needs to construct SOAP Envelope, and then send the
> message to the end web service. In this way, how does the client
> invoke the web service should be transparent to the end web services.
> And thus there should be no classification of SOAP web services or
> REST web services. In stead, these two are only two invocation styles.
> Is my understanding correct?

Yes that is correct.

> 5. What's the real usage of REST style?

I think Anne answered this question very well. In REST there are no
services, there are just resources. So the world is very different if
you do full REST .. what you do is not even SOA then its something like
a "resource oriented architecture". 

In Axis2 what we're trying to do is to allow you to use "native HTTP"
POST and GET to talk to the services. Whether you use it to implement a
REST religion compliant architecture or a SOA religion compliant
architecture is not our concern.


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

View raw message