我一直在阅读有关.NET Web服务版本控制的解决方案，即
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
等等;并且似乎还没有（在任何Microsoft框架中）成为一个完美的答案。有很多意见认为URL改变是要走的路;在REST环境中说的其他人使用HTTP标头/内容标题/接受标题等来定义版本以及您将接受的输出。
在.NET世界中，从WSDL生成引用并获取intellisense为我做。它抽象了很多“提升”，让我称呼我的方法。
然而，在维护和发布其他版本的过程中，更新API，扩展Web服务变得越来越困难。
我还没有看到下面描述的解决方案。它似乎在testrig中运行良好;但没有人建议它，因为它是一个愚蠢的想法，或者只是一个混合的想法，刮伤了当前的痒？
我们每个月发布一个主要Web应用程序的新版本，错误修复，新功能和功能扩展，所以我正在寻找易于维护的东西，但Web服务的消费者不担心升级，直到他们想要（在合理范围内），而不是为每个版本/ URL创建预先存在的Web服务的完整副本。
基本上建议是：
客户服务 出现在1.0版并具有URL /API/WebServices/V1.0/Customer.asmx
该应用程序的1.1版本出现了，没有更改客户Web服务，因此在/API/WebServices/V1.1/Customer.asmx上重写了一个URL到/API/WebServices/V1.0/ Customer.asmx
该应用程序的1.2版本出现了，没有对客户Web服务进行任何更改，因此在/API/WebServices/V1.2/Customer.asmx上重写了一个URL到/API/WebServices/V1.0/ Customer.asmx
依旧......
，然后
在版本1.3中我们想要添加另一种方法 - 很棒我们（因为添加另一种方法而不改变任何“当前”方法不会破坏在v1.0上运行的任何远程应用程序）只需添加其他方法（测试自己确保我们没有犯任何愚蠢的错误）并在/API/WebServices/V1.3/Customer.asmx上发布。这一次是一个“新”的Web服务，它基本上是我不喜欢这个 - 任何更好的想法？只是1.0的webservice文件的副本添加了新方法。 Web Service文件本身尽可能简单，所有逻辑和其他所有类/核心文件都可能，因此它没有真正的逻辑（它实际上是一个端点接口）。 我们去V1.4，V1.5 V1.6都是对V1.3服务的重写。
打破向后兼容性 现在我们需要改变一些东西/改变它的工作原理，所以我们为V1.7创建了一个新的web服务 - 复制V1.3代码并开始修改直到我们完成。
我认为这个想法允许远程消费应用程序在需要时升级，我们的任务是确保旧服务继续工作，直到我们正式停止支持旧版本，允许早期采用者获得最新功能，允许我们继续发布每个月都有一个新版本，每当有人说“客户服务的URL是什么？”时我们可以简单回答：
http(s)://example.com/API/WebServices/**versionNumber**/Customer.asmx
它将始终有效。 （除非我们将它删除了）。
这是一个愚蠢的想法吗？一个合理的想法，或者我一直在使用错误的关键字谷歌搜索，这已经被破解了？