WCF与REST API技术疑问：为何REST早提出却后流行？求解析SOAP过时原因

Hey，作为一个在.NET圈子里折腾了十几年的开发者，我来好好拆解一下你这个问题——这里面其实藏着技术选型的时代背景逻辑，还有微软的战略转向，不是简单的「谁比谁更优秀」的问题。

回到2006年那个时间点，你得先把当时的技术生态捋清楚：

• 微软手里的服务开发技术是碎片化的：.NET Remoting（用于进程内/跨进程通信）、ASMX Web Services（早期SOAP服务）、WSE（处理安全等高级特性的Web服务增强包），这些技术各管一块，开发者要根据不同场景切换，学习成本高，维护起来也头疼。
• 当时企业级服务的主流是*SOAP/WS-规范：这是微软、IBM等大厂共同推动的一套企业级通信标准，主打可靠、安全、跨平台，银行、大型企业的内部核心系统几乎全靠这套体系支撑。

WCF的本质就是微软想做一个大一统的服务框架：它把之前的各种技术整合到一个体系里，支持多种绑定（HTTP、TCP、MSMQ、命名管道等），能适配从本地进程通信到跨企业远程服务的所有场景，还内置了WS-*的全套特性（安全、可靠消息、事务）。而当时REST还只是学术圈和小众领域的概念，企业级市场根本没起来，微软推WCF完全是符合当时技术主流和企业需求的最优选择。

这个转变核心是时代需求彻底变了：

• 移动互联网的爆发：2010年后智能手机普及，移动端带宽有限、设备性能远不如服务器，需要轻量化的通信协议。REST基于HTTP原生方法（GET/POST/PUT/DELETE），用JSON传输数据，比SOAP臃肿的XML信封简洁太多，传输效率高，开发调试也简单（浏览器直接敲URL就能测GET请求）。
• 云原生和微服务的兴起：现在的系统都是分布式、微服务架构，需要轻量、松耦合的通信方式。WCF的很多特性（比如会话、可靠消息）在微服务场景下反而显得冗余，而REST的无状态特性刚好契合微服务的设计理念，容器化部署也更友好。
• 微软自身的战略转向：后来微软明显看到了REST的趋势，推出了ASP.NET Web API（现在整合到ASP.NET Core），彻底拥抱REST。现在.NET Core生态里，WCF基本是维护旧系统的角色，新项目没人会选它——毕竟Core的Web API更轻、更快，还能跨平台。

SOAP的没落其实和它的设计定位绑定在一起：

• 复杂度拉满：SOAP有一堆WS-*扩展规范，比如WS-Security、WS-ReliableMessaging、WS-AtomicTransaction，每个都要复杂的配置，学习成本极高，开发调试也麻烦（得生成代理类，用专门的工具测试）。
• 性能劣势明显：XML序列化和反序列化的开销很大，加上SOAP信封的冗余结构，在高并发场景下性能远不如JSON+HTTP。
• 生态全面萎缩：现在几乎所有云服务商、第三方API都用REST，新的开发框架（比如Spring Boot、ASP.NET Core）对SOAP的支持越来越弱化，只有一些遗留的大型企业系统还在坚持用SOAP，新项目没人会再选它了。

总结一下：技术从来没有绝对的优劣，只有是否适配当下的需求。WCF在2006年解决了.NET服务碎片化的痛点，是当时的最优解；而REST则契合了移动互联网和云原生的浪潮，成为现在的主流。如果是维护旧系统，WCF还得用，但新项目肯定优先选REST API。

内容的提问来源于stack exchange，提问作者Kabir