How do you manage change with your web services?

Question

Over time your web service might changes, what do you do and how do manage change? (Different versions; add more features, modify or even remove features etc)

Answer 1

Typically, for non-breaking changes (mainly addition of methods), you can extend the service contract/implementation in same end-point. Again, when I say non-breaking changes, it means both syntactic and semantic changes.

Otherwise, cleanest way to do is to host new service version on different end point all together. Give your clients chance to migrate to newer version gradually before shutting down the old version (if needed). Many times, you can use most of your service implementation behind the scene and reduce efforts.

Also, sometimes service changes are not in methods but in input/output data. These can be tackled some times by versioning your data structures. For example, a function accepting XML input may start supporting additional data/tags in input. In such case, you may host it on same end-point and then figure out from data what client is sending. Although, I would prefer to have another method or new end point in such case.

Lastly, you can have also have method in your service interface that can emit version info or validate version info provided by client to tell it whether the service implementation is compatible with whatever service contract it has built with. This allows clients to give friendly messages in case of incompatibility or incorrect configuration. Yet another variation in such scenario can be to return client the end-point address of the compatible service version (sort of dynamic discovery of compatible service).

Answer 2

I would add a new endpoint that could use the same code in the backend but just return different output.

If the change is small enough (like just a new property) then ideally you could just update the output of your existing service endpoint; Adding the new proprety to your output and have older clients ignore that. The problem though is that consumers of soap (especially in the .NET world) use tooling which generates static proxies which are very inflexible to change.