Web service: single line parameter or complex type parameters

Question

Is it more or less acceptable (i.e. standard) to create a public web service with these method signatures:

ThisMethodDoesSomething(ComplexType param) ThisMethodDoesSomethingElse(AnotherComplexType param) 

Or that:

 ThisMethodDoesSomethingAndSomethingElse(string xml) 

If the operation being performed depends on an XML string passed to a single all-all-all method? I always left with the first, but my colleague prefers the latter, and I try to weigh the pros and cons of both strategies before we start a new project. What is more acceptable and easier for the public to work on and why?

Answer 1

I would never send an XML string. First of all, “XML” is not the same as “string”. They do not follow the same rules.

Any sensible client can accept a complex type consisting of primitive types and lists or arrays of primitive types, recursively (C # syntax):

 public class ComplexType1 { public int IntegerProperty {get;set;} public int[] ArrayOfIntegers {get;set;} public List<int> ListOfIntegers {get;set;} // Same as ArrayOfIntegers } public class ComplexType2 { public ComplexType1 CT1 {get;set;} public List<ComplexType1> LCT1 {get;set;} } 

Honestly, any client who cannot handle something similar above deserves to be fired.

Answer 2

Previously, I would prefer the latter, because I was not sure that if in a cross-platform situation each SOAP client could correctly use complex types. So I thought of a SOAP call that just takes and returns (XML) Strings don't give me a headache. In the meantime, I experienced, as a rule, no problems with the first approach, at least for .Net interaction with JAVA / AXIS and vice versa. I'm still looking to make the complex type not too complicated though.

I assume that ThisMethodDoesSomething() and ThisMethodDoesSomethingElse() are atomic operations? If this is not the case ( ThisMethodDoesSomethingElse() requires calling ThisMethodDoesSomething() to execute), the first approach is not.

Answer 3

I prefer (and this is the operational word, prefer, since there is no standard for this) is a complex XML string that explains the action. You can see this from my open source project .

Some of the reasons I prefer ...

• Your actions are an interpreted language that can bend.
• Activities can be combined into one network trip.
• XML allows you to expand the set of functions without violating past functions.
• The XML hierarchy allows actions to act on the server side.

Answer 4

Your question sounds to me like a question of a coarse-grained and fine-grained interface at first glance. On the other hand, I feel that the second approach takes the grain to the extreme, if you know what I mean. You lose all type checks. You complicate the implementation very much - you will need many cases if you really find out what the request is inside the support code. How will the method return? I assume that if you just get the string as a parameter, you will return another string. Since this is a String, and I assume this is a string representation of an XML document, you will have to parse some of your support code. As the interface expands, I assume that they will turn into divine methods. The list goes on :)

As a side note, don't think I'm in favor of very thin interfaces. There must be a balance between them. The rule for me would always be to pass an element.

Answer 5

I usually create an xml schema to describe the messages that will form my interface. Then, using the xsd generator for a class such as Castor or Microsoft xsd.exe, I create implementation classes.