Backwards compatibility and Web Services
So I'm a bit new to web services and a situation recently came up where we added an element to a data-type that gets returned to the client. The clients complained that this broke their implementation because it choked on the new element that it did not expect. (we are providing the services via Axis2).
To me this seems like a harmless change that the client should be able to handle gracefully (I've worked with some non-web-service frameworks where adding optional information was completely acceptable). I could understand if we deleted or renamed some fields that that would cause issues for the client.
Basically I would expect the wsdl to act like an interface. If we make a change that essentially subtypes that interface, I would expect the client to happily ignore extraneous elements. Is this just a short coming of web services, or is there a sane way of making passive changes to the services so that new clients can get the extra data while old clients can update at their leisure?
Answer
WSDL actually acts as a contract more than an interface. The WSDL describes exactly what the operation expects to "receive" and what it expects to "return". The closest analogy to this would be in C changing the prototype for a function without changing the function itself, they wont match and that causes problems.
The more specific the WSDL is the more behavior you are "guaranteeing" to be in place.
If you need flexibility in your returned data (i.e. adding/removing fields etc) you can do one of the following:
- Version your WSDL definitions and publish services that can redirect older versions to newer versions
- Use more abstract data return types, such as XML to hide the complexity or changing data.
2 has some more risk, but it can be managed with XSDs or other technologies. Your particular project requirements will dictate what is acceptable.