目标是构建一个服务，然后我将通过jQuery和基于标准的Web前端，移动设备“胖客户端”，以及很可能是WPF桌面应用程序来使用。
看起来WCF会是一个不错的选择，但我从来没有用WCF构建RESTful服务，所以我不确定从哪里开始这个方法。
我正在考虑的另一个选项是使用ASP.NET MVC，添加一些自定义路由，添加一些控制器操作并使用不同的视图来推出JSON，xml和其他返回类型。
这个项目主要是我自己的学习练习，我想花一些额外的时间来做“正确”，这样我就可以更好地了解各个部分是如何组合在一起的。
所以我的问题是，我应该使用哪种方法来构建这种RESTful服务，这样做有什么好处？
答案 0 :(得分：8)
通常情况下，我会说WCF适用于任何类型的托管服务，但在使用JSON作为序列化机制的RESTful服务的特定情况下，我更喜欢ASP.NET MVC（我将其余部分称为ASP.NET）这个答案）。
首要原因之一是由于路由机制。在WCF中，你必须在合同上定义它，这一切都很好，但如果你必须快速更改路由，从我的角度来看，使用ASP中的路由机制更容易。 NET。
此外，对于上述问题，如果您在WCF中通过多个接口公开了多个服务，则很难获得URL结构的完整图像（这很重要），而在ASP.NET中（通常）拥有所有在一个地方的路线分配。
关于ASP.NET的第二件事是你将能够访问ASP.NET所知的所有内部对象（请求，响应，服务器等等），这在暴露HTTP时是必不可少的。特定端点（这是您正在创建的）。当然，您可以在WCF中使用许多相同的东西，但是您必须明确告诉WCF您正在这样做，然后考虑到这一点设计您的服务。
最后，通过个人经验，我发现DataContractJsonSerializer没有很好地处理DateTimeOffset值，而且在工作时应该使用DateTime的类型通过多个时区的人可以调用的服务（在任何端点上）。在ASP.NET中，您可以使用不同的序列化程序，或者如果需要，您可以创建自己的ActionResult，它为您使用自定义序列化程序。我个人更喜欢JSON.Net serializer。
我喜欢的JSON.Net序列化程序和ASP.NET的一个好处是你可以使用匿名类型，如果你很聪明的话。如果在非泛型类型上创建静态泛型方法然后委托给内部泛型类型，则可以使用类型推断来轻松地为序列化返回值使用匿名类型（假设它们是一次性的，当然，如果您有一个一致返回的结构，你应该定义它并使用它。
还应该提到的是，如果开发RESTful服务，则不必完全折扣WCF。如果您从服务中推送ATOM或RSS源，那么大量的System.ServiceModel.Syndication命名空间中的类有助于构建和序列化这些源。创建ActionResult类的简单子类以获取SyndicationFeed的实例，然后在执行ActionResult时将其序列化为输出流非常简单。
答案 1 :(得分：4)
这是一个可以帮助您在ASP.NET MVC和WCF之间做出决定的思想。在您描述的场景中，您是否希望使用HTTP以外的协议？
WCF旨在与传输协议无关，因此它与ASP.NET非常不同。它具有渠道和绑定，消息，服务合同，数据合同和行为。在构建分布式应用程序时，它几乎没有提供指导。它给你的是一个干净的石板建立。
ASP.Net MVC自然是一个基于Http的框架。它处理HTTP动词，媒体类型，URL，响应头和请求头。
问题是哪种模型更接近你想要建立的模式？
现在你提到了ReST。如果您确实希望按照ReST约束构建分布式应用程序，那么最好从OpenRasta开始。它将指导你走这条路。
你可以在ASP.Net MVC中做Rest，你可以在WCF中做到，但是使用这些解决方案，你不会陷入成功的陷阱;-)
答案 2 :(得分：1)
就个人而言，我并不是在WCF中实现REST服务。我发现asp.net mvc框架是一个更自然的编程模型。
http://atomsite.net/的实现者最初在WCF中实现了atompub规范，然后使用asp.net mvc重写了整个服务。他的经验与我上面的评论相呼应，对于纯粹的REST服务，asp.net mvc是可行的方法。
唯一的例外是，如果我想以一种宁静而非宁静的方式展示服务。或者，如果我通过REST公开现有的WCF服务。