Trying to compare the advantage of a web service method returning complex type or xml string in different situations.
It looks more generic to return a xml string to represent the complex type object, but if so, what is the need to make a web service return a complex data type (i.e. a pojo, a bean). I know there must be some sort of judgment (depends on the use case) to pick either one, what is your standards to determine which approach to choose?
Originally posted by Ricky Murphy: Trying to compare the advantage of a web service method returning complex type or xml string in different situations.
For one thing a SOAP web service always returns XML (or MIME for attachments).
The client decides what to do with that XML. Often code-generation tools are used to generate the code to un-marshal the XML to a bean (which may look nothing like the original complex type on the server) for expediency sake. However using static stubs is "static binding" which is a form of tight-coupling. Prodding the result XML with some XPath expressions to extract just the minimum amount of data required is a more loosely coupled approach (which requires more effort because it requires more manual coding). Finally the client could decide to simply keep the XML as is, especially if it uses an XML-based infrastructure, though it's likely that it would run an XSLT transformation on it to change it to a more suitable format for its domain.
subject: Web service return complex data type vs. XML string