Good questions. The way I see it, support for REST has more to do with
hype than anything else -- especially the way it's been implemented.
(which really is POX rather than REST)
There is a growing backlash against the complexity of SOAP and WS-*,
and in response, people are looking for a simpler, more native-Web
approach to services. And that's POX -- Plain Old XML over HTTP. HTTP
is a very powerful and scalable application protocol. It supports
clean separation of header and application payload. It provides a
means to support self-describing messages (using MIME types). It
supports security (HTTPS) and stateful sessions (cookies). Many argue
that the SOAP envelope and all the SOAP Headers are just a lot of
extra clutter. And for many applications, that's true. POX is
absolutely adequate.
But POX does not automatically imply REST. REST is an architectural
style -- one that is resource-oriented rather the service-oriented. If
you think that you can take a service-oriented application and
generate a resource-oriented interface for it, then you really don't
understand REST. If you want a RESTful system, it requires a different
design model -- the two architectural styles (service vs
resource-oriented) are fundamentally different.
Let me explain using Mark Baker's favorite example -- lightbulbs.
Let's say you want to design a system that allows you to turn
lightbulbs on and off.
When designing a service-oriented systems, your design center is the
service and the set of operations it can perform:
Service: LightbulbManagement
Operation: setState
Input: lightbulbID [int], state [On | Off]
Output: void
Operation: getState
Input: lightbulbID [int]
Output: state [On | Off]
Note that you have a single service, which manages all lightbulbs, and
you tell the service which lightbulb to process. Each operation has a
unique URL.
When designing a RESTful system, your design center is the resource,
and each resource (in this case a lightbulb) has a unique URL, and
each resource is manipulated using a uniform interface (GET, PUT,
POST, DELETE):
Resource: Lightbulb
Operation: GET
Output: state [On | Off]
Operation: PUT
Input: state [On | Off]
As you can see, it requires a significantly different design center.
Anne
On 8/31/06, Xinjun Chen <[EMAIL PROTECTED]> wrote:
Hi,
I read through the Axis2 documentation about RESTful support from
http://ws.apache.org/axis2/1_0/rest-ws.html.
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?
2. If the client send a request in a RESTful way, will there be no
SOAP headers on the wire? Does this improve efficiency?
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? Without the WS-Addressing, can we still
have another way to build and invoke stateful web services?
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?
5. What's the real usage of REST style?
Regards,
Xinjun
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
