Are there benefits of writing a web service interface whose methods all take and return XML documents, rather than the more usual parameter lists of native types and classes?
We have some existing web services that are designed like this. The XML documents that are passed to their methods are typically large (as in they contain maybe 100 pieces of data that are relevant to the method calls). We have XSD files that we use to validate the XML documents, but the overall client developer experience is poor and slow. Surely it would be preferable to have a strongly-typed interface?
The web services are written in C#, and the clients are written in C# and also Java (some of our business partners use Java).
If you absolutely know for sure what your end-user/client technology is (for example pure .NET and Java where the feature set is probably the richest) then by all means go ahead and take advantage of strongly typed interfaces where available. But if your client base is a mixed bag of Perl, PHP, ASP, Python etc, then I’d keep life simple and accessible for these folks.
We have a number of web services that have to be consumable by this sort of mixed bag of clients, and whilst I’d love to make life simple for us, we have to dumb down a bit purely to ensure maximum interoperability.