We ran into an interesting problem with one of our web service interfaces at work today. We had recently added code to enforce some business logic constraints, and this was causing some requests to fail that, from the perspective of the UI, should have been legal. The problem was a mismatch between the granularity of our service contract and the granularity of the constraints.
The constraints that we had added were ones that applied to collections of objects. An example of this type of constraint is that a collection of nodes in a graph cannot have any cycles. The interesting thing about this sort of constraint is that you cannot determine if the constraint is being violated by looking at a single node. You have to examine all of them at once.
Now suppose that you have a web service call that allows you to add/remove/update a single node. Superficially this doesn't seem like a bad idea. In addition to that, let's assume that the application making use of the service allows the user to modify one or more nodes and then save all the changes back to the server. No problem, when it comes time to save the changes to the server, you iterate through the modified nodes and then make an add/update/delete call for each one.
But what if the server validates the set of nodes as part of each add/update/delete call. Now you've got problems. The user can make a set of changes that are consistent when considered as a whole. That is, the graph resulting from all the changes has no cycles. However, it is possible that one or more of the individual changes results in a cycle. So part way through saving the changes back to the server, you'll get an error indicating that the constraint has been violated.
The problem is that the granularity of the updates does not match the granularity of the constraint. To resolve the mismatch for the example above, you need a service method that allows all the changes to be sent to the server as a batch. The server will only validate the results after the entire batch of changes has been applied.
You might feel inclined to complain that a web service that allowed the nodes to be updated individually was a poor design in the first place. After all, most service interfaces should allow operations to be carried out in bulk. But even if you design the service to support bulk changes, it is still possible that the granularity of the interface does not match the granularity of constraints -- so when designing a service interface you need to be aware of the business constraints that will be enforced by the service implementation and design your interface accordingly.