不使用WebAPI的原因

Question

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

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

我最初认为在跨平台的SOA架构中,WebAPI可能不尽如人意,但是我阅读的文章越多,我越发现WebAPI几乎在每个现实场景中都可能胜过WCF.看起来你可以使用WebAPI for 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%保证匹配,编译器检查和类型安全(de)序列化.

如果您还拥有完整的CI,则可以消除因签订不匹配合同而发布二进制文件的风险.Web API序列化更加宽容,因此验证和测试更加复杂(客户端可以发送数据服务器不期望,服务器可以发送数据客户端不期望.)WCF还支持合同版本控制和扩展数据,这样只允许中间服务知道V1合约仍然可以接受并转发到V2或更高版本的消息,同时保留了解V2或以后合同的服务的所有数据!)

WebAPI主要用于以最小的挫败感实现基于HTTP的服务,因此,WebAPI在很大程度上依赖于asp.net HTTP Web Stack来运行(而WCF及其基础不支持,事实上,一些WebAPI功能直接依赖于WCF.例如,通过WebAPI公开OData源.)

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

WCF不仅支持所有这些,它还具有高度可配置性,允许您通过配置文件和代码在可用传输的MOST,格式化/序列化,安全性,实例化,生命周期和其他服务设置之间进行混合和匹配.

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

但是,与任何技术一样,WCF只会让您的开发人员对网络和基础架构有所了解.放在平庸或不情愿的手中,你将得到一个完整的混乱,无法执行.WebAPI有点简单,即使是初学程序员也可以在几分钟内使用它,并且通常可以成功完成任务.

2C