看起来WCF会是一个不错的选择,但我从来没有用WCF构建RESTful服务,所以我不确定从哪里开始这种方法.
我正在考虑的另一个选项是使用ASP.NET MVC,添加一些自定义路由,添加一些控制器操作并使用不同的视图来推出JSON,xml和其他返回类型.
这个项目主要是我自己的学习练习,我想花一些额外的时间来做“正确”,这样我就可以更好地了解各个部分是如何组合在一起的.
所以我的问题是,我应该使用哪种方法来构建这种RESTful服务,这样做有什么好处呢？
解决方法
第一个原因之一是由于路由机制.在WCF中,你必须在合同上定义它,这一切都很好,但如果你必须快速更改路由,从我的角度来看,使用ASP中的路由机制更容易.净.
此外,对于上述问题,如果在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时将其序列化为输出流非常简单.
