Hi Sanjiva,
On 9/2/06, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
Hi Anne,
> 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)
As I said in my reply, in Axis2 we do support more than POX- we also
support GETs. But in principle I agree with your comment .. REST is full
of hype these days. In Axis2 we *do not* do full REST (with etag support
and all .. although I am working with Ruwan Linton on a caching module
that will support it).
POX doesn't imply just supporting POST. POX simply means that you are
formatting the payload as plain XML, without a separate envelope. If
you need to pass additional system-levle information, that should be
specified in the HTTP header or the MIME header. Sometimes POX is
RESTful, and sometimes it isn't. That's an issue of design, not
protocols.
Note that a lot of folks that are campaigning against WS-* for its
complexity (e.g., Tim Bray) are not proposing REST as an alternative
-- just POX.
> 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
Now you've drunk too much REST coolaid Anne ;-) .. MIME is not self
describing when it comes to XML .. saying application/xml simply isn't
enough to "describe" the XML; you do need a schema of some sort.
Ah ... but you don't have to use application/xml. You can define your
own MIME type to type the specific document. And you don't have to
register a MIME type in order to use 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.
+1.
> 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.
Big +1.
> 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.
And just to make sure people understand- when this example was discussed
in http://groups.yahoo.com/group/service-orientated-architecture/, there
was a thread of like 100 messages that got quite a diversity of
opinions. Moral of the story: achieving REST style architectures
properly is just as much of an art as achieving SOA properly.
Sanjiva.
---------------------------------------------------------------------
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]
