Chatura, See my use cases- http://issues.apache.org/jira/browse/AXIS2-68
Richard, Please add your use cases here too. thanks, dims On 7/7/05, Chathura Herath <[EMAIL PROTECTED]> wrote: > > > > Yup it does both. > > http://ws.apache.org/axis2/rest-ws.html > > > > Cheers > > Chathura > > > > > ________________________________ > > > From: Richard Wallis [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 07, 2005 5:08 AM > To: [email protected] > Subject: RE: REST again > > > > > > Robert, > > > > Sadly [having spent several hours lost in the Axis 1.2 code line] I think > you are right. > > > > I note from the Axis 2-0.9 release email '* REST Web Service Support' I > need to download and have a look I certainly hope its not 'either SOAP or > REST' I hope its both. > > > > Richard. > > > ________________________________ > > > From: Robert Lowe [mailto:[EMAIL PROTECTED] > Sent: 06 July 2005 22:57 > To: [email protected] > Subject: Re: REST again > > My gut feeling is that, if you want to provide both SOAP and REST > interfaces, your best bet would be to use Axis' messaging style (where you > treat the request and response bodies as raw XML), and then use an > Axis-independent Java-XML data binding technology (e.g. JAXB, Castor, > XMLBeans) to translate between XML and Java objects. You'd then be able to > reuse the data-binding code (but not the Axis code) in the REST services. > > It sounds like Axis2, JAXB 2.0 and JAX-RPC 2.0 all aim to make this easier, > but if you need both SOAP and REST services today I'd consider the above > approach. > > > Richard Wallis wrote: Jeff, > > Couldn't agree more with your analysis. > > WSDL/SOAP more than has its place, but there is demand out there that is > pushing REST to the top of the hit parade. You only have to look at the > take-up of Amazon AWS. I believe it still 80% REST, 20% SOAP. (That 80-20 > rule turns up everywhere !) > > So why's that then? Its because the barrier to participation for developers > is so much lower for REST. Anyone who can construct a URI in a web browser > and read, or transform to html, the xml that is returned has proven that > they can access and invoke a service. All they then have to do is build an > application around it. > > In the emerging world of Web 2.0, AJAX, etc. building the killer app that > consumes [web] services is now getting easier and easier. > > Does that spell the demise of WSDL/SOAP? - Definitely not! > > Firstly we still need to service the 20%, and that 20% are the enterprise > apps that need the robustness & control of WSDL/SOAP & WS-*. > > Secondly, the WSDL/SOAP environment is a structured & controlled one that is > ideal for developing services. This is especially true if you follow the > "invest your effort in correctly defining your WSDL before cutting code to > deliver service it defines" mantra. > > So where I'm coming from is that once having produced a service [defined by > WSDL etc.] you should almost by default then offer the same service via > REST. The benefits, provided that REST can be added at low development > cost, then come from providing simple test environment [a browser can become > you WS test tool] and a low barrier for others to use your services in ways > you never expected. > > As I said in my previous mail, I'm digging around the area of Axis Servlet > Query String Plug-ins to see how easy it would be to be provide a simple > REST façade to a deployed service. > > Of course I'll report back on progress, but if in the meantime anyone wants > to chip in with help, advice, and comments, please do. > > Richard. > > > > > -----Original Message----- > From: Jeff [mailto:[EMAIL PROTECTED] > Sent: 29 June 2005 04:35 > To: [email protected] > Subject: Re: REST again > > Hi, > > Some of my customers use REST. Initially, I thought that it was a little > dumb, given the possibility of orthogonal services from SOAP. I came to the > conclusion a few months ago that REST is actually better than SOAP for many > situations! I still use Axis daily but for future projects I am likely to > stop. Here's why... > > First of all, I only ever write document-literal web services. I prefer to > move documents around because they are something that have more of a > tangible existence than mere parameters. I am happy using non-Axis > technologies to read/write XML payloads, I don't need the Axis data model. > That is not sufficient reason not to use Axis, of course. > > Consider signing and encrypting SOAP messages: upon receipt the payload is > extracted by decryption and the signature is checked BUT thenceforth the > security has gone. In my situation it's better to sign and/or encrypt > documents so that when SOAP envelopes are discarded I still have security. I > can move documents around at will and their original signature is in place. > > Routing SOAP messages is a good example of an orthogonal service that SOAP > provides but how many people actually use routing? I guess SOA stuff does. > Those people who need routing can just as easily redirect URLs in REST. > > As I said, I started off convinced that SOAP was the way to go and, without > any pressure from any REST person, I came to the conclusion that REST is > simpler and better. Here's what pushed me over the edge: when using document > payloads, the documents often reference other documents but for such things > to work seamlessly with SOAP we have to think about endpoints and all that > stuff. With REST, we simply have another URL. In the REST world, all > resources are readily accessible as URLs and this simplicity provides a more > uniform environment without losing functionality. > > As originally conceived, SOAP provided a way for doing RPC over the web and > was driven by the desire for Microsoft to achieve the platform independence > of Java without actually having to support other platforms. For RPC that's > still valid. For documents, we already have a document-centric > infrastructure provided by HTTP. > > > Jeff > > > ----- Original Message ----- > From: "Richard Wallis" <[EMAIL PROTECTED]> > To: <[email protected]>; "Anne Thomas Manes" <[EMAIL PROTECTED]> > Sent: Wednesday, June 29, 2005 11:09 AM > Subject: RE: REST again > > > To quote a famous tennis player "You can not be serious!" > > Having defined an implementation independent interface to a service > [using WSDL] and built functionality to deliver it [greatly helped by > the auto-generation of objects by wsdl2java] having the inputs & outputs > validated by the underling Axis-SOAP infrastructure you are suggesting > that the best way to get at the same service via a different protocol is > to go off and recreate the core functionality. > > Apart from the obvious can of worms you would be building up for future > code maintenance, the fact that the XML output from a REST service call > would be identical to the contents of the envelope body from its SOAP > equivalent leads one to consider that there should be a massive > opportunity for reuse here. > > I have been thinking about this since my original posting, whilst > digging around in the Axis code base especially in areas such as > AxisServlet.doGet(), and > org.apache.axis.transport.http.QSMethodHandler > [which almost does what I want except it makes some strange assumption > that the service method and the root data element of the request body > have the same name]. > > It should not be too difficult to create QSMethodHandler equivalent > which maps url parameters to a SOAP request body [based upon the wsdl > for the relevant service] and then call the service within the currently > running Axis engine. In the same way extracting the contents of the > response body and returning that as the REST response should not be too > difficult. Or am I being naive? > > If I'm not being naive, I would be willing to take a look at doing it > but would need some help from members of the community who know their > way around the code line far better than I do. > > Thoughts, comments, and offers of help ? > > Richard. > > > > -----Original Message----- > From: Anne Thomas Manes [mailto:[EMAIL PROTECTED] > Sent: 28 June 2005 12:27 > To: [email protected] > Subject: Re: REST again > > REST works on the assumption that your applications are > working directly with the XML and not attempting to map Java > objects to XML. > If your assignment is to provide the same service in REST, > then you should in fact recreate all the functionality, but > this time using DOM in your application rather than mapping > everything to objects. > > Anne > > On 6/22/05, Richard Wallis <[EMAIL PROTECTED]> wrote: > > > Following the 'Start with the WSDL!' principle of web service > development, I have produced a successful service which > > works in both > > > Axis & .net, greatly helped by the classes produced by wsdl2java. > > So far so good. Now I have a requirement to provide the > > same service > > > via REST. Being lazy I don't want to recreate all the > > functionality > > > so intend to directly call the service method in the auto-generated > xxSoapBindingImpl class. I can easily create the correct Object to > pass as a parameter. > > The problem I next have is to be able to create a response XML > Document from the Object returned from the method. Axis > > must do this > > > when it is creating the response SOAP Body. > > Does anyone know how I can easily access this functionality. > > Richard. > > > Register your interest now > Insight 2005 : 15th & 16th November > Register your interest now http://www.talis.com/events > > > > Any views or personal opinions expressed within this email > > may not be those of Talis Information Ltd. The content of > this email message and any files that may be attached are > confidential, and for the usage of the intended recipient > only. If you are not the intended recipient, then please > return this message to the sender and delete it. Any use of > this e-mail by an unauthorised recipient is prohibited. > > > > > Register your interest now > Insight 2005 : 15th & 16th November > Register your interest now http://www.talis.com/events > > > > Any views or personal opinions expressed within this email may not be those > of Talis Information Ltd. The content of this email message and any files > that may be attached are confidential, and for the usage of the intended > recipient only. If you are not the intended recipient, then please return > this message to the sender and delete it. Any use of this e-mail by an > unauthorised recipient is prohibited. > > > Register your interest now > Insight 2005 : 15th & 16th November > Register your interest now http://www.talis.com/events > > > > Any views or personal opinions expressed within this email may not be those > of Talis Information Ltd. The content of this email message and any files > that may be attached are confidential, and for the usage of the intended > recipient only. If you are not the intended recipient, then please return > this message to the sender and delete it. Any use of this e-mail by an > unauthorised recipient is prohibited. > > > > > > > > > -- > > Best regards, > Robert Lowe > > http://rmlowe.com/ > > > > > > > Insight 2005 15th & 16th November > > Register your interest now > > > Any views or personal opinions expressed within this email may not be those > of Talis Information Ltd. The content of this email message and any files > that may be attached are confidential, and for the usage of the intended > recipient only. If you are not the intended recipient, then please return > this message to the sender and delete it. Any use of this e-mail by an > unauthorised recipient is prohibited. -- Davanum Srinivas -http://blogs.cocoondev.org/dims/
