is it ok to combine multiple functions to a single operation in wsdl?

Question

Is there a "rule" for this? What i'm wondering is there best practice that tells how to combine functions to an operation. For example SetRecord-operation: if id is specified for some kind of record the operation updates the record otherwise the operation creates the record. In this case return message would tell if insert or update was made, but would this be bad design (and if it is, why)?

Another example would be that there's contains-hierarchy of records and sometimes it's wanted to create all levels of hiearchy, sometimes 2 levels and sometime only 1. (bad) Example would be hiearchy car-seat-arm rest. Sometimes only a car or a single seat is created. Sometimes a car with 4 seats (each having 2 arm rests) is created. How this is supposed to map to wsdl-operations and types. If you have opinion i would like to know why? I must say that i'm bit lost here.

Thanks and BR - Matti

Answer 1

Although there's no problem on doing that, it violates some principles of good programming patterns.

Your methods and also your classes should do only one thing and no more then one. The Single Responsibility Principle says exactly that:

The Single Responsibility Principle (SRP) says that a class should have one, and only one, reason to change. To say this a different way, the methods of a class should change for the same reasons, they should not be affected by different forces that change at different rates.

It may also violates some other principles, like:

Separation of concerns
Cohesion

I don't even have to say that it can lead to a lot of Code Smells like:

Long Method
Conditional Complexity

Check this good text.

Answer 2

I made some research and i think the answer above is presenting quite narrow view of wsdl inteface design. It is stupid to combine my question's example Insert and Update to Set in a way that the operation done is deduced on the data (checking if id or similar filled in request message). So in that kind of case it's bad because the interface is not really stating what will happen. Having 2 separate operations is much more clear and does not consume any more resources.

However combining operations can be a correct way to do things. Think about my hiearchical data example: It would require 13 request to have a car with 4 seats with all having both arm-rests. All border crossings should be expected as costly. So this one could be combined to single operation.

Read for example:

Is this the Crudy anti pattern?

and

http://msdn.microsoft.com/en-us/library/ms954638.aspx

and you will find out that your answer above was definitely over simplification and all programming principles can't be automatically applied in web service interface design.

Good example in SO-answer above is creating 1st order header and them orderitems with separate requests is bad because e.g. it can be slow and unreliable. They could be combined to

PlaceOrder(invoiceHeader, List<InvoiceLines>)

So the answer is: it depends what you are combining. Too low level CRUD-kinda thing is not way to go but also combining things not needed to be combined shouldn't be. Moreover defining clear interface with clear message structures that tells straight away what will be done is the key here instead of simplyfying it to multiple / single.

-Matti