Re: [AXIS2] Should JSON messages be considered as REST?

[Sanjiva Weerawarana]

I think the whole question of "REST" is not the point here. Axis2's underlying data model is a SOAP Infoset. As a result, any type of data that runs thru the system has to be represented as a SOAP Infoset. That's not a big deal - essentially it means we need to create two extra Axiom nodes (a s:Envelope node and an s:Body node) and stick a child in there that contains whatever the real data is. Using our nice MTOM integration and the deferred pull architecture of Axiom, we can do that efficiently using OMSourceElement nodes as we've proven multiple times now. That's for incoming stuff - we take whatever that comes in and represent it within a SOAP Infoset. When we have an outgoing message, the inverse question is relevant - if the message is not going out as SOAP, then someone needs to take the real message payload (which is in the child node of the s:Body node) and only write the content of that. That's basically what MessageFormatters do. [So calling all of that "REST" is totally wrong and an abuse of what "REST" means. I think we need to refactor that code and get rid of any references to REST as this has nothing to do with REST. Yes I know the history and how it got called that but now its time to fix it.] Now to get back to your original point - I think the idea of having message formatters applied to faults too (which you proposed in a later mail) is the right answer. Faults are just messages too and its clearly an oversight that we didn't apply the design orthogonally there too. Time to fix it. Sanjiva. keith chapman wrote: Let me describe the problem in more detail. As of now Axis2 enables you to plug in various message types by registering them in the axis2.xml. Some of these message types will be SOAP based (like text/xml and application/soap+xml) while others are not. And in the latter case when a exception occurs somewhere in the pipe we do not want to throw the fault as a SOAP message. What we do in the REST case of of now is that  we take the fault element in the SOAP body (If not found the first child of the SOAP body) and write that out as the fault. As of now Axis2 treats a few message Types as REST specifically application/xml, multipart/form-data and application/x-www-form-urlencoded. But with the pluggable message types in place this may not work that well. Assume that someone want to to plug in application/foo and that this message type is REST how are we gonna handle it? Should we consider adding a attribute to the messageBuilders/messageFormatters section to indicate weather its REST or not? Thanks, Keith. On Sat, Sep 20, 2008 at 3:22 AM, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote: +1 .. but I'm a bit confused. I assume by "REST" you meant that the response has media type text/xml instead of application/soap+xml, right? If we think about it that way, can we get rid of the "isDoingREST" flag?? (I've hated that from day 1 and haven't had a chance to really dig thru it and figure out how to get rid of. Maybe this is an opportunity to get it right ..) Sanjiva. keith chapman wrote: Any input on this would be appreciated. Thanks, Keith. On Thu, Sep 4, 2008 at 8:40 AM, keith chapman <[EMAIL PROTECTED]> wrote: Hi devs, This idea came up because of the following scenario. Currently the logic for creating a AxisFault  for a fault received lies in org.apache.axis2.util.Utils.java (lines 507 - 530). This works perfectly when the received fault is SOAP or REST. But it does not work as expected when the response is JSON ( rather a exception is thrown saying "The MessageContext does not have an associated SOAPFault."). The reason is the logic we use to build the AxisFault. If the fault message is not a SOAP message we check for the flag messageContext.isDoingREST() and get the first element of the SOAPBody as the fault message. When the fault message is JSON its neither SOAP and the messageContext.isDoingREST() returns false. Should we consider  JSON messages as REST messages? I believe so. WDYT? Thanks, Keith. -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Sanjiva Weerawarana, Ph.D. Founder & Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Keith Chapman Senior Software Engineer WSO2 Inc. Oxygenating the Web Service Platform. http://wso2.org/ blog: http://www.keith-chapman.org -- Sanjiva Weerawarana, Ph.D. Founder & Director; Lanka Software Foundation; http://www.opensource.lk/ Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ Member; Apache Software Foundation; http://www.apache.org/ Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ Blog: http://sanjiva.weerawarana.org/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]