wcf - 不使用 WebAPI 的原因

Question

我一直在研究 WebAPI 并且非常喜欢我所看到的。

有理由不使用 WebAPI 吗？如果是这样，在什么情况下？

我最初认为在跨平台的 SOA 架构中，WebAPI 可能会达不到要求，但是我阅读的文章越多，我就越意识到 WebAPI 在几乎所有现实场景中都可能击败 WCF。看起来您可以将 WebAPI 用于 android、ios 等，而不仅仅是用于 .Net；甚至性能显示 WCF REST 最慢。 http://weblog.west-wind.com/posts/2012/Sep/04/ASPNET-Frameworks-and-Raw-Throughput-Performance

WCF 是否还有更好的“明显”原因？

Answer 1

每当您控制消费者和提供者端点(例如后端服务到服务通信)时，您都应该使用 WCF(或套接字)来获得功能和性能。通过 WCF 托管服务然后共享二进制合约意味着客户端和服务器之间 100% 保证匹配、编译器检查和类型安全(反)序列化。

如果您还拥有完整的 CI，那么您几乎可以消除发布带有不匹配合约的二进制文件的风险。 Web API 序列化更宽容，因此验证和测试涉及更多(客户端可以发送数据服务器不期望，服务器可以发送数据客户端不期望。) WCF 还支持契约(Contract)版本控制和扩展数据，这允许中介服务只知道 V1 合约仍然可以接受并转发到 V2 或更高版本的消息，同时保留理解 V2 或更高版本合约的服务的所有数据!)

WebAPI 主要用于以最小的挫折实现基于 HTTP 的服务，因此，WebAPI 在很大程度上依赖于 asp.net HTTP Web Stack 来运行(而 WCF 及其基础并没有，事实上，一些 WebAPI 功能直接依赖于 WCF。 . 例如，通过 WebAPI 公开 OData 提要。)

与 Web API 端点类似，WCF 端点可以配置为在必要时通过 HTTP 提供访问(以及其他协议(protocol)和技术，例如安全命名管道、MSMQ、UDP、TCP 等)。WCF 也是可扩展的，并且开箱即用为双工、双向和可靠消息传递提供传输实现，它使用 token 、证书、基本身份验证凭据等提供传输级和消息级身份验证。对服务发现、订阅、广播等有额外的支持(诚然，WebAPI 提供了一些重叠，但控制级别不同。)

WCF 不仅支持所有这些，而且高度可配置，允许您通过配置文件和代码在大多数可用传输、格式化/序列化、安全性、实例化、生命周期和其他服务设置之间进行混合和匹配。

现在将您的两个中间层一起移动到同一台机器中？切换到命名管道。将服务器从 .net 交换到 PHP？没问题，将绑定(bind)配置从使用 net.tcp 更改为使用 soap。 WebAPI 停止的地方，WCF 继续。

但是，与任何技术一样，WCF 的亮点在于开发人员对网络和基础架构的理解。放在平庸或不情愿的人手中，你会得到一团糟，无法执行。 WebAPI 更简单一些，即使是初学者程序员也可以在几分钟内使用它，并且通常会成功完成他们的任务。

2c