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? 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? Regards, Xinjun On 9/3/06, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
