为什么我需要WCF来构建RESTful服务？

我最近发现了一种使用Global.asax实现RESTful服务的方法（通过处理Application_BeginRequest事件）。基本上，我认为在传统ASP.NET中实现RESTful Web服务是可能的（也是容易的），而不需要WCF。为什么我需要WCF来构建RESTful服务？

它需要约30行代码来确定你想调用哪个方法（来自URL），并将它的参数（从查询字符串，通过反射）传递给它，并使用XmlSerializer对结果进行序列化。这一切都会导致可以通过HTTP GET请求访问的Web服务，并返回标准的XML数据。

因此，有鉴于此，是否有任何理由在创建仅通过HTTP GET请求调用的RESTful Web服务时使用WCF？ WCF引入了大量的开销和限制，而上面描述的Global.asax方法更容易实现，定制和部署。

注 - JSON端点也可以在不使用WCF的情况下通过使用JavaScriptSerializer来实现。

另外 - HTTP POST请求可以用类似的方式由Global.asax来处理。

所以最后，在这种情况下使用WCF的原因是什么？有更好的可伸缩性或性能吗？

来源

2010-07-24 dacris

是的 - 当然 - 如果你只需要REST，你可以推出自己的。无论如何，我会使用WCF，因为：如果您突然需要通过SOAP公开您的服务方法，例如使用tcp/ip的内部使用，或类似的东西？如果你自己推出了，你现在必须移动到WCF，或者你自己也滚动整个SOAP支持。 WCF只是给你很多选择 - 大部分是通过配置 - 如果你需要它们的话。 – 2010-07-24 10:19:20

你也可以使用Asp.Net MVC来实现REST非常简单。

你没有得到免费的这种方法是什么：

非HTTP绑定。
支持多种消息格式。
非IIS托管。
控制过程激活。
控制实例创建。
对象池。
消息排队。
交易。
可扩展性和可靠性。
在WCF之上构建的其他技术，如OData支持。

如果这些都不适用于您的方案 - 您不需要WCF。

来源

2010-07-24 08:45:35

如果这些都不适合和“从不”将会 – 2010-07-24 09:00:06

答案是，2个不同的管道，但WCF管道是专门为服务构建的，并且ASP.Net是为通过HTTP呈现内容而构建的。两者都有其优缺点。

如果您对ASP.net堆栈感到满意，并且不必担心标准等问题，那么ASP.Net就可以。

但是，如果您想要两全其美，请尝试使用WCF Data Services，WCF的所有酷炫内置功能，而不用麻烦。目前，MVC没有生成OData的视图引擎。

来源

2010-07-28 03:59:16

为什么我需要WCF来构建RESTful服务？

回答

相关问题