Best Practices?: Versioning Web Services

Posts   
 
    
Devildog74
User
Posts: 719
Joined: 04-Feb-2004
# Posted on: 09-May-2006 04:30:50   

There is some debate on what an ideal web service interface would look like at my organization. The debate revolves around how to write our web service interface so that new methods do not break existing consumers.

Some people would have us write web methods like this:


// this is very granular
[WebMethod]
public int CreateClient(string clientName, string clientId, string address1, string address2){}

Others would have us write the method like this.... // this is very object oriented and less granular [WebMethod] public int CreateClient(ClientDocument clientToAdd){}

And others would have us write the method like this: // this is very generic [WebMethod] public int CreateClient(string manifest, string payload){}

I think the only people that agree on the first example, are the architects that have never maintained code or written code for backward compatibility, so 90% of all the tech leads and developers do not dig the first approach.

The majority of the shop thinks the second approach is preferred because in the event that you need to add new methods, you just add them and redeploy the web service. Meanwhile, existing clients work the same and new clients consume the new method with the new foot print. I also beleive that we can base our services around an Interface and use the adapter pattern to create new functionality.

People that prefer the third approach are relying on the client passing in a proper manifest definition. The contents of the manifest variable would be used to load a factory that parsed the payload into business objects, and then delegated the work to a template method in the factory object. The template method of the factory object would invoke an xml reader and parse the payload and do the work. My personal opinion is that this puts too much weight on the consumer of the service, meaning that the consumer has to know too much about the method they are invoking.

So my personal feeling is that the second method is the way to go. Since everyone knows what opinons are like, i.e. everyone has one, I thought I would ping the users of my favorite forum and see how the other down to earth people handle versioning of web services.

Walaa avatar
Walaa
Support Team
Posts: 14983
Joined: 21-Aug-2005
# Posted on: 09-May-2006 09:15:14   

The majority of the shop thinks the second approach is preferred because in the event that you need to add new methods, you just add them and redeploy the web service. Meanwhile, existing clients work the same and new clients consume the new method with the new foot print.

I'm in favour of the second approach too, just in order not to have too many parameters to pass, this can be a headache sometimes.

But I don't see why your quoted words can not be applied to the first approach too? You can always add new methods to web services without annoying old methods users.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39749
Joined: 17-Aug-2003
# Posted on: 09-May-2006 10:55:11   

It's more and more going to be 'messages messages messages' in webservice world, which means that first focus on the message, define the contract, then write the code. This then automatically dictates how the methods will look like. So it doesn't mean you will end up with option 2, but it's LIKELY you'll end up with using a DTO or message object. In that light, option one versions better than option two, as you can add properties to the message object, without breaking anything.

Frans Bouma | Lead developer LLBLGen Pro
npathuru
User
Posts: 17
Joined: 14-Jun-2005
# Posted on: 09-May-2006 16:03:26   

Just thought this may be of help: Another approach you could follow:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=381042&SiteID=1

thanks.

Devildog74
User
Posts: 719
Joined: 04-Feb-2004
# Posted on: 09-May-2006 17:34:42   

Thanks again for your thoughts.

jeffreygg
User
Posts: 805
Joined: 26-Oct-2003
# Posted on: 09-May-2006 19:46:19   

Hey, Devildog. Check out these articles by Rocky. They represent a great concept and seem to be the best option for maximum maintainability/versioning in a services paradigm.

http://www.lhotka.net/WeBlog/MessagebasedWebMethodOverloading.aspx http://www.theserverside.net/articles/showarticle.tss?id=SOAVersioningCovenant

The articles lean toward your second option, except that a) the return type is also a document (more in line with true request/response messages, etc) and b) they take the concept that the semantic function AddCustomer() shouldn't change, only the contents of the message. Once this is done, the versions are handled internally and the external semantic function serves merely as a MessageRouter to the appropriate, internal RPC-style functions (AddCustomer1(), AddCustomer2(), etc) based on the message's schema.

So, I guess a combination of your second and third options, except that the consumer doesn't have to know anything about the versions, or constructing a proper manifest. Also, WCF has a "KnownTypeAttribute" that can be used as a de facto MessageRouter pattern to forward messages of a specific schema to specific business methods.

Anyway, my two cents.

Jeff...

Devildog74
User
Posts: 719
Joined: 04-Feb-2004
# Posted on: 10-May-2006 14:09:40   

Interesting, I will have a look.