WCF Rest - 最佳实践是什么?

3
刚刚开始我的第一个WCF rest项目,希望在使用REST时能得到一些帮助。我看过许多教程,似乎有很多方法可以做到同样的事情...例如,如果进行POST操作,我看过一些教程是设置HttpStatusCodes(OK/Errors等),而其他教程则只返回包含操作结果的字符串。最终,总共有4个操作,肯定有一份指南会告诉你如果要进行GET操作,应该这样做,如果进行POST操作,应该这样做...任何帮助将不胜感激。JD

1
REST最佳实践:不要使用WCF REST。就像瘟疫一样避免它。 - Aliostad
3个回答

6

更新

使用ASP.NET Web API。


好的,我留下了评论REST最佳实践:不要使用WCF REST。就像避开瘟疫一样避免它,我觉得我需要解释一下。

WCF的一个基本缺陷是它只关注有效负荷。例如FooBar在这里是有效负荷。

[OperationContract]
public Foo Do(Bar bar)
{
    ...
}

这是WCF的一个原则,无论传输方式如何,我们都能将载荷传送给您。但它忽略了调用的上下文/信封,在许多情况下,这是特定于传输的 - 因此,很多上下文都会丢失。事实上,HTTP的强大之处在于其上下文而不是负载,在早期版本的WCF中,无法在netTcpBinding中获取客户端的IP地址,WCF团队坚称他们无法提供它。我现在找不到那个页面,但记得阅读评论和微软的人只是说不支持。
使用WCF REST,您失去了在以下方面清晰表达自己的HTTP灵活性(后来不得不妥协):
- HTTP状态码 - HTTP媒体类型 - ETag等
Glenn Block开发的新Web API通过封装上下文中的有效负载来解决此问题。
public HttpResponse<Foo> Do(HttpRequest<Bar> bar) // PSEUDOCODE
{
    ...
}

但是根据我的测试,这并不完美,我个人更喜欢使用像Nancy或者纯ASP NET MVC这样的框架来暴露Web API。


ASP NET MVC 不仅适用于构建传统的 Web 应用程序。 - Aliostad
@Aliostad: :) 现在我更加困惑了。我认为答复会像Richard的那样,并且设置StatusCodes等等。我们即将开始一个WCF项目,你会说选择ASP.net MVC而不是仅使用WCF Rest(即使没有视图,我们只是返回JSON数据)? - JD.
1
http://servicestack.net/ 看起来是 WCF 的一个严肃/更好的替代品。可以与 asp.net mvc 一起使用。 - Robin van der Knaap
在.NET 4中,您可以抛出WebFaultException而不是使用WebOperationContext,并且有助手处理诸如NotFound和Created之类的事情。但是,我会使用Web API而不是现有的基础结构。我知道MVC不仅用于创建传统网站,但是REST需要更多的内容,例如使用动词URI和返回不同的内容类型-对于这些额外的内容,您必须在MVC中手动编写支持,而它已经内置到Web API中。 - Richard Blewett
2
@JD 所谓现有的基础设施,我指的是当前的 .NET 4.0 版本 - 它们在简单情况下是可用的,但如果您想要更完整地支持 HTTP 并且希望开箱即用地支持常见的 REST 短语,那么新的 Web API 绝对值得考虑。 - Richard Blewett
显示剩余8条评论

6

使用不同的HTTP动词时,有一些基本规则,这些规则来自于HTTP规范

GET:这是一个纯读取操作。调用不得导致服务状态发生更改。根据缓存头信息,GET的响应可能会从缓存(本地、代理等)中提供。

DELETE:用于删除资源。

有时会对PUT和POST产生一些混淆——什么情况下应该使用哪个?要回答这个问题,你必须考虑幂等性——即操作是否可以重复执行而不影响服务状态。例如,将客户姓名设置为某个值可以多次重复执行而不会引起进一步的状态更改;然而,如果我正在增加客户的银行余额,则不能安全地重复执行而不在服务上进行进一步的状态更改。前者被认为是幂等的,后者则不是。

PUT:非删除的幂等状态更改。

POST:非删除的非幂等状态更改。

REST采用HTTP协议,因此失败应使用HTTP状态码进行通信。200表示成功,201表示创建,服务应返回新资源的URI使用HTTP位置标头,4xx表示由于客户端请求的性质而导致的故障(因此可以通过客户端更改其操作来修复),5xx表示只能在服务器端解决的服务器错误。

感谢提供的信息。考虑到AlioStads的评论,我需要重新思考是否选择WCF Rest框架。不过,你的建议对我做出决定非常有帮助。 - JD.

0

这里有一些需要说的内容。

WCF Rest 可能无法提供 REST 协议的所有功能,但它能够为现有的 WCF 服务提供 REST 协议的支持。因此,如果您决定在当前的 SOAP/Named pipe 协议之上提供某种形式的 REST 支持,那么这是一个不错的选择,特别是当 ROI 较低时。

手动编写完整的 REST 协议可能是理想的,但并不总是经济实惠的。在我的 90% 项目中,REST API 是事后考虑的。在这方面,WCF 非常方便。


此外,如果您想要Wcf REST针对HTTP上下文的上下文感知行为,它是高度可定制的。一个例子是XML / JSON切换。http://robbincremers.me/2012/01/05/wcf-rest-service-with-xml-json-response-format-according-to-content-type-header/这篇文章描述了如何使用内容类型标头切换格式。再次强调,我同意这并不理想,但也不完全是一片灰暗。 - Sleeper Smith

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接