RESTful Web服务

这是WCF REST Web服务的一个良好起点:

REST / SOAP endpoints for a WCF service

(顺便说一句:stackoverflow有很好的REST类型的URL。) 您可以只使用Web浏览器测试REST服务(转到URL并获取XML或JSON)。Fiddler也是一个很好的工具,火狐的Firebug插件。我通常做一个瘦服务接口项目和一个单独的(单元测试的)逻辑项目。

对于身份验证,我将首先生成一个guid和一个时间戳。然后根据这些哈希(.net支持sha256和sha512)。可以将guid存储到服务器(数据库表)以将其映射为一些具体的数字ID。然后您可以拥有一个类似以下的REST URL:

/myobject/1?timestamp=20100802201000&hash=4DR7HGJPRE54Y 

只需在开发环境中禁用哈希和时间戳检查(例如,使用AOP)。使用时间戳,我将检查该时间戳是否在15分钟前后(应该足以防止攻击)。

您的服务对公众/互联网可见吗?您的客户端是jquery还是Silverlight客户端?然后您仍然有一个问题:您不想在客户机软件代码中包含一个密钥。

因此,您需要在服务器和某种cookie中生成哈希来存储客户机会话。(这可以通过不同配置文件的文件夹中的单独登录页面/应用程序来完成。)我记得 this book 有关于这个话题的内容:

如果要在使用wcf时启用httpcontext,则需要设置 <serviceHostingEnvironment aspNetCompatibilityEnabled="true"> 在下面 <system.serviceModel> . 然后您可以从 HttpContext.Current.User.Identity.Name .

但是,如果您想创建一个纯REST服务,那么就不使用cookie,而是为每个调用使用一个HTTP基本身份验证和SSL/TLS。

我认为只使用linq2xml或jquery创建客户机很容易,因此可能不需要生成客户机。

或者您也可以同时拥有SOAP和REST接口,并使用服务引用生成客户机。

首先要记住的是,REST服务应该是无状态的,与SOAP/RPC类型的服务接口相比,这是非常不同的。使用REST方法需要您重新考虑您希望客户机如何与服务交互,将交互分解为清晰简洁的方法调用。

休息
+轻量级消息,很少开销(除了XML本身)
+易于阅读的结果,可以使用Web浏览器轻松测试
+易于实施
-接口松动,类型检查松动

肥皂
+更严格的合同定义
+提供了大量的开发工具。

通过查看wcf msdn文档,从一开始就集成了wcf soap支持,而rest支持是最近添加的一个功能。我自己很难找到REST服务的身份验证/安全性文档,因为大多数文档都指向SOAP。

客户端生成工具:我没有遇到任何for-rest服务,因为REST没有像SOAP那样定义服务契约。Wadl是一个为休息服务的尝试。 http://en.wikipedia.org/wiki/Web_Application_Description_Language http://wadl.codeplex.com/

我很有兴趣阅读更多关于身份验证和安全性的响应,因为我自己也在研究这个问题。

要记住的一点是,你可以把休息作为一种哲学(所有东西都应该可以通过一个干净的URL访问,而不附加隐藏的字符串)或教条(你必须使用Put和Delete,即使这意味着很多困难)。

重点是简化——比如为参数使用简单的数据类型,而不是结构的pileups,或者由于多余的原因(比如在URL中拖拽巨大的页面“title”)而阻塞接口,而不是使用不知名和事实上的标准的标题。

因此,您可以使用Web浏览器的“获取并保留可用性和可测试性”来设计完美的RESTful界面。您还可以使用任何标准身份验证方法或其中的一些方法进行冗余,具体取决于您的实际目标受众。如果你正在用标准化的证书和令牌在一个corpnet上运行一个应用程序,你可以继续使用它。如果您正在做一些非常普通的访问,您可以使用get args和/或cookies的组合-保持您的url-s对99.99%的用户是干净的。

您甚至可以同时提供JSON和XML(例如,GoogleMaps),并且仍然可以重新填充,但不能使用全尺寸SOAP(复杂的输入类型等)。您可以为请求执行有限的SOAP简单类型,始终可以表示为get args,人们仍然可以获得文档的WSDL。

希望这画出足够灵活的画面——超越任何严格教条的思维方式。