少有人走的路

webapi和wcf的比较

（一）webapi的特点

最明显的特点是它是一种资源为导向的通讯方式。

使用标准HTTP动词如GET、POST、PUT、DELETE等，适用于所有的资源的增删改查操作，使得使用变得简单明了。

WebApi使用轻量级的Json格式进行数据传输，相比WebService使用的XML格式，传输性能有明显的提升

WebApi完全支持路由，使得URL的设计更加灵活。同时，它还支持模型绑定和验证，提高了数据的安全性

而相比wcf或者webservice来讲，它们是以功能函数为导向的，它的功能都是一些方法调用。

（二）webapi能完全取代wcf吗？

答案是不能，见下面：

Web API主要基于HTTP协议，是一种针对HTTP的、偏重于快速开发RestFul风格开放式API的开发框架。
它允许开发人员通过HTTP协议进行通信，实现不同系统之间的数据交互和功能调用。
Web API的优势在于跨平台和跨语言，可以在不同平台和不同编程语言之间进行交互，以及简化开发过程。

而WCF（Windows Communication Foundation）则是一个更为广泛和复杂的通信框架，它整合了原有的.NET通信机制，
如.NET Remoting、WebService、Socket等，并融合了HTTP和FTP等相关技术。WCF以契约（Contract）来定义双方沟通的协议，
这些契约可以以接口的方式体现，实际的服务代码则必须由这些契约接口派生并实现。
WCF支持多种通信协议，包括但不限于pipe、TCP等，
这使得它在全范围传输协议、安全选项、事务以及可靠性方面相对于Web API具有更广泛的适用性。

因此，虽然Web API在某些场景下可以作为WCF的替代方案，但由于其在通讯协议上的局限性，无法完全替代WCF。
开发者在选择使用Web API还是WCF时，应根据具体需求和场景来做出决策。
如果Web API可以满足需求，那么使用它可能是更合适的选择；
如果需要更广泛的通讯协议支持或其他WCF特有的功能，那么可能需要考虑使用WCF。

（三）实际上，应该用web api来二次封装wcf的服务，这是常见的用法

使用Web API封装来自WCF（Windows Communication Foundation）的服务以供多个项目使用是完全可行的，并且是一种常见的做法。
这样做的好处是可以将旧的WCF服务与新的、基于HTTP的Web API架构集成，
使得其他项目（无论是基于.NET的还是非.NET的）都能够通过HTTP请求来调用这些服务。
通过这种方法，你可以将WCF服务的功能暴露给更广泛的客户端，同时保持对服务的封装和控制。

此外，由于Web API是基于HTTP的，因此它可以轻松地与各种客户端和框架集成，包括Web浏览器、移动应用程序、桌面应用程序等。
将WCF服务封装成Web API后，你就可以同时从前端（如使用JavaScript的Web浏览器或移动应用）
和后端（如其他Web服务、桌面应用或后台任务）访问这个Web API了。

这是因为Web API遵循RESTful（Representational State Transfer）架构风格，它使用HTTP协议进行通信，
并通过URL来定位资源。这种基于HTTP的通信方式使得Web API具有跨平台、跨语言的特性，
任何能够发送HTTP请求并处理HTTP响应的客户端都可以与之交互。

对于前端来说，你可以使用JavaScript的fetch API、axios库、jQuery的$.ajax方法等
来发送HTTP请求到Web API，并处理返回的响应数据。

对于后端来说，你可以使用各种编程语言和框架来发送HTTP请求到Web API。
例如，在C#中，你可以使用HttpClient类来发送请求；在Python中，你可以使用requests库；
在Java中，你可以使用HttpURLConnection或Apache的HttpClient库等。

总之，将WCF服务封装成Web API后，你就可以利用HTTP协议的通用性和灵活性，
实现前后端之间的松耦合通信，并且支持多种客户端的访问。

本文出自勇哥的网站《少有人走的路》wwww.skcircle.com，转载请注明出处！讨论可扫码加群：