RE: REST again

[Chathura Herath]

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: axis-user@ws.apache.org 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: axis-user@ws.apache.org 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: axis-user@ws.apache.org 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: <axis-user@ws.apache.org>; "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:27To: axis-user@ws.apache.orgSubject: Re: REST again REST works on the assumption that your applications areworking directly with the XML and not attempting to map Javaobjects to XML.If your assignment is to provide the same service in REST,then you should in fact recreate all the functionality, butthis time using DOM in your application rather than mappingeverything to objects. Anne On 6/22/05, Richard Wallis <[EMAIL PROTECTED]> wrote:    Following the 'Start with the WSDL!' principle of web servicedevelopment, 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-generatedxxSoapBindingImpl class.  I can easily create the correct Object topass as a parameter. The problem I next have is to be able to create a response XMLDocument 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 nowInsight 2005 : 15th & 16th NovemberRegister 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 ofthis email message and any files that may be attached areconfidential, and for the usage of the intended recipientonly. If you are not the intended recipient, then pleasereturn this message to the sender and delete it. Any use ofthis e-mail by an unauthorised recipient is prohibited.           Register your interest nowInsight 2005 : 15th & 16th NovemberRegister your interest now http://www.talis.com/events   Any views or personal opinions expressed within this email may not be thoseof Talis Information Ltd. The content of this email message and any filesthat may be attached are confidential, and for the usage of the intendedrecipient only. If you are not the intended recipient, then please returnthis message to the sender and delete it. Any use of this e-mail by anunauthorised recipient is prohibited.  Register your interest now Insight 2005 : 15th & 16th NovemberRegister 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.