我可以从配置为调用 .asmx 服务的客户端调用 Web API 吗？答案

【问题标题】：Can I call Web API from a client configured to call an .asmx service?我可以从配置为调用 .asmx 服务的客户端调用 Web API 吗？
【发布时间】：2015-10-07 17:01:54
【问题描述】：

我正在考虑将现有的 Web 服务转换为 Web API。我只与 WS 合作过一点点，那是很久以前的事了。我记得的是，在我的项目中，我会引用一个服务位置，然后使用该引用来调用我需要的任何方法。例如：我会引用http://mydomain/webservicename/mobile.asmx，然后调用 objWS.MethodName() 什么是在 mobile.asmx 文件中编码的。

如果我转换为使用 Web API，我基本上会通过转到 http://mydomain/controllername/myMethod 之类的东西来调用 HTTP。

截至目前，我无法访问客户端代码来更改它调用服务的方式。话虽这么说，我是否坚持使用传统的 Web 服务与 Web api？

这是我认为运行 Windows CE 的手持扫描仪上的应用程序。我们遇到了一些连接问题/数据库死锁，我被要求查看它，看看是否可以提供帮助。当前的 WS 代码在 IMO 中过于复杂，因为它只对数据库进行插入或更新。我还认为使用 Web API 会使其成为更快的应用程序，因为它依赖于蜂窝访问进行通信。 JSON 应该是比 XML 更小的负载。

所以，我想使用 Web API 2 和实体框架重新编写它。但是，恐怕我坚持使用 WS，因为我无权访问客户端代码。

有什么建议吗？

【问题讨论】：

标签： c# asp.net web-services asp.net-web-api

【解决方案1】：

这是一个相当广泛的架构建议，但您提出的建议听起来确实可行，甚至相当合理。

如果我理解正确，您目前有这个：

Client -> ASMX Service

而且您不能更改客户端，只能更改 ASMX 服务。您要做的第一件事是确保服务器端业务逻辑与平台技术分离：

Client -> ASMX Service -> Business Logic

这里的想法是任何应用程序主机都应该能够合理地调用相同的业务逻辑，即使该逻辑只不过是直接数据库访问。应用程序宿主本身应该只是要调用的传递操作集。

此时，您可以在第一个应用程序主机旁边创建第二个应用程序主机：

Client -> ASMX Service ----|
                           |-> Business Logic
          WebAPI Service --|

所以现在您有两个不同的服务，它们使用两种不同的 Web 服务技术公开相同的业务逻辑。它们中的每一个都应该非常薄，因为应用程序主机技术应该始终可以轻松替换。

此时，假设两个服务之间的可用操作没有明显差距，您可以向客户发布新服务的规范并开始计划弃用旧服务。当您可以弃用它时，它更多的是合同问题而不是技术问题。无论您承诺维护它多久，客户就会有合理的期望继续使用它。

如果您真的想要，您甚至可以让 ASMX 服务成为 WebAPI 服务的传递，但根据我的个人经验，这会在整个设置中添加不必要的分层并人为地使业务逻辑的抽象。无论哪种方式，ASMX 服务公开的接口都不会改变。

这里的主要内容是对所公开操作的逻辑抽象以及分析 ASMX 服务可以做什么和 WebAPI 服务可以做什么之间的任何差距。如果这变得复杂，那么这表明业务逻辑（实际上是整个解决方案域）与正在使用的应用程序技术紧密耦合，即 ASMX Web 服务。那就是要解决的问题。解决后，创建不同的应用程序主机并公开调用相同底层业务操作的不同服务几乎变得微不足道。

【讨论】：

【解决方案2】：

你是对的；如果您无法更改客户端并且想要更改服务协议，那么您将陷入困境。您的客户端当前具有配置为指向的特定 .asmx 端点，直到您可以更新该端点并让客户端停止使用从服务生成的代理，您才能更改为 Web API。

不过，我仍然会重写服务以使用 EF。

【讨论】：