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