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

[Sanjiva Weerawarana]

Thilina Gunarathne wrote: Hi, Hope I'm not too late to catch up... In reply to Eran's questions about the fundaments, >Then the question comes as to what really Axis2 is. If we enable plugging custom types, which are not compatible >with SOAP or REST, then aren't we redefining what Axis2 is? Do we wanna make it something which can handle >more than Web services (I consider "REST within Axis2" also as Web services, as our REST implementation is >based on WSDL 2.0 HTTP binding) What we mean by custom types in the context of MessageBuilders/formatters is that different serializations of the XML infoset. One example would be fast infoset. When supporting JSON we are using the existing XML<-->JSON transformation standards (or rather agreements) and I beleive this can also be called as a different searialisation of XML infoset..  On the other hand I personally consider a pure JSON service as a web service too... No I think your statement is too strong - yes, we support different XML Infoset serializations too via the MessageBuilder/Formatter architecture but its a lot more than that because of how we ended up doing non-SOAP stuff. Not only can we serialize the SOAP Infoset (as an XML Infoset) into a different XML serialization, but we can also write message formatters and builders that use the integrated MTOM stuff and OMSourcedElement stuff (which you did IIRC!) to keep ANY kind of content. In fact those can even fail if you ask for the payload as XML (or may not)- so if you take a JSON message and serialize as XML then Bablefish or whatever will kick in. However if you ask to serialize as JSON directly then NO transforms will occur and the JSON characters should go in and out seamlessly. >I don't think so because in the spec once again it says the following here : http://www.w3.org/TR/wsdl20->adjuncts/#_http_operation_xml_encoding >"The instance data of the input, output or fault message is serialized as an XML document in the message body >of the HTTP message" Since JSON serialization is not XML, rather name/value pair, application/xml is not >compatible with application/json. As I said earlier we can consider it as XML since we are using XML<--> json conversions standards like Badgerfish or Mapped. See above. Back to the proposed solutions, >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. >With current MessageBuilders/ >MessageFormatters they build/format requests based on content-type. I'm not too familiar with the fault message >flow in Axis2 (Will have a look on that and get back)  But why arn't we allowing the corresponding builder/formatter >to format faults too? If that was the case I think this problem would not occur. Looks like the fundemental problem >lies in there. The messagefomatter interface[1] defines how to write the SOAP message  it receives to the wire. It does not differentiate anything about the content of the message (eg: fault or not)..  IMHO it's up to the author of the message formatter to decide whether he is going to treat it diffrently or not..  Even in the case of JSON, I do not see anything wrong if our JSON formatter serialised the whole SOAP message (including SOAP). If it serializes just the payload then it is just simply a decision by the message format author. Yes - and there's nothing at all wrong if the JSON formatter just printed the payload out in JSON either! What the formatter decides to serialize is a decision up to that .. and the real contract is between the formatter and the builder when they are coupled in a request/response MEP. That is, a message coming in via JSON should probably go out via JSON, unless some type of content negotiation has kicked in to ask for a different response format. (BTW did you ever do the content negotiation stuff we discussed? Or was that with Keith .. gettin' old. Maybe we should get content negotiation working right too in the context of this cleanup. Its not hard.) On a side note I see value in providing a configuration option to the JSON formatter to select whether to serialize the whole message or just the payload (isDoingPOX?).. May be the builders can use some magic to figure this out looking at the received messages. I would expect the fault to be treated same as the message (rip off the SOAP if it's doing so for the non-fault messages).. I think the JSON builder should build the payload only and the formatter should serialize the payload only. Others are welcome to write other JSON formatters that print the SOAP stuff too but IMO that's not the common case. On the other hand, I consider it as a huge bug if Axis2 is not applying the message formatters to the Fault flow at all.. IIRC considered the fault flow and we did this for the fault flow too, so that it'll use the corresponding formatter/builder in case of a fault.. OK good - we're all in agreement that not doing the faults was a mistake! Sanjiva. -- 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]