2

I have been reading around the solutions to versioning on .NET web services i.e.

http(s)://example.com/API/WebServices/v1.0.0/Customer.asmx
http(s)://example.com/API/WebServices/v1.1.0/Customer.asmx
http(s)://example.com/API/WebServices/v1.2.0/Customer.asmx

and so on; and there doesn't seem to be yet (in any Microsoft Framework) to be a perfect answer. There are lots of opinions that URL changing is the way to go; Others that say in a REST environment use a HTTP header/Content Header/Accepts Header etc to define the version and what output you will accept.

In a .NET world generating your references off the WSDL and getting intellisense does it for me. It abstracts a lot of the "lifting" and lets me call my methods.

However in the world of maintaining and releasing additional versions, updating the API, extending web services it is getting difficult.

I have not seen the solution described below suggested. It seems to work fine in a testrig; but has no one suggested it because its a daft idea, or is in just a hybrid idea which scratches the current itch?

We release a new version of the main Web App, bug fixes, new features and feature extensions maybe once a month so I am looking for something easy to maintain, but the consumers of the webservices to not worry about upgrading until they desire (within reason) whilst not creating a complete copy of a pre-existing web service for each version/URL.

Basically the suggestion is:

Customer Service Appears in Version 1.0 and has URL /API/WebServices/V1.0/Customer.asmx

Version 1.1 of the app comes out, with no changes to the Customer web service, so have a URL re-write on /API/WebServices/V1.1/Customer.asmx to /API/WebServices/V1.0/Customer.asmx

Version 1.2 of the app comes out, with no changes to the Customer web service, so have a URL re-write on /API/WebServices/V1.2/Customer.asmx to /API/WebServices/V1.0/Customer.asmx

and so on....

Then

in Version 1.3 we want to add another method - great we (as adding another method and not changing any of the "current" methods will not break any remote apps running on v1.0) just add the additional method (test ourselves to ensure we have not made any silly mistakes) and release at /API/WebServices/V1.3/Customer.asmx. This time being a "NEW" web service which is basically I don't like this bit - any better ideas? just a copy of the webservice file from 1.0 with the new method added. The Web Service file itself is as bare bones as possible with all logic and everything possible in other class/core files so it has no real logic (its effectively an endpoint interface).

on we go V1.4, V1.5 V1.6 are all re-writes to the V1.3 service.

Breaking backward compatibility Now we need to change something / change how it works so we create a new webservice for V1.7 - copy the V1.3 code and start to modify until we're done.

This idea I think allows remote consuming apps to upgrade when they want, our task is to ensure the old services keep working until we officially stop supporting the old version, allows early adopters to get the latest functionality, allows us to keep issuing a new version every month and whenever someone says "Whats the URL for the Customer Service?" we can answer simply:

http(s)://example.com/API/WebServices/**versionNumber**/Customer.asmx

and it will ALWAYS work. (unless so old we removed it).

Is this a daft idea? a reasonable idea or have I been Googling with the wrong keywords and this has already been cracked?

user1971085
  • 21
  • 1
  • 2
  • Why are you asking this question about ASMX web services and ignoring any benefits that WCF may offer in this area? – John Saunders Jan 11 '13 at 20:48
  • Looks fine to me. I think the tradeoffs and limitations are reasonable with the solution you've outlined. – ashes999 Jan 11 '13 at 20:49
  • Hi John - I came across some routing related stuff in my research (WCF 4.0) but nothing that I see makes WCF better than the traditional .asmx route. What am I missing? What would/could WCF give me thats worth moving across for? – user1971085 Jan 11 '13 at 21:41
  • Found http://www.codeproject.com/Articles/426776/WCF-Top-10-Interview-Questions which while interesting to add additional protocol support and so on - its not giving us anything we don't already have that I can see. And I am not sure the version issue has been addresses in WCF either? – user1971085 Jan 11 '13 at 21:51
  • Well I have added a Web reference, in a Test App, to a version of my Web Service operating with a server side redirect. Generating the reference seems fine; and then executing a call to this "shadow" web service I have changed the URL in the client (as lets say I am now calling a later version of the web service i.e. WebService.Url = "http://{IPAddress}/WebServices/v2.6.5/OrderService.asmx" – user1971085 Jan 12 '13 at 12:02
  • darn connection drop out - (so continues from above) .... ) and this works fine returning complex data types as well. – user1971085 Jan 12 '13 at 12:09

0 Answers0