RESTful Web 服务

Posted 2023-05-07

【中文标题】RESTful Web 服务

【英文标题】：RESTful web services

【发布时间】：2011-03-19 04:17:29

【问题描述】：

我是 的新手。我们正在采用 REST 路线来构建供外部客户使用的公共 Web 服务。我有几个问题。

纯 REST Web 服务是否有任何限制？如果是，那么混合 REST Web 服务会解决这些限制吗？

我正在考虑在授权标头中使用 SSL + 哈希消息身份验证代码 (HMAC) 以确保安全性以及基于 IP 的过滤。大家怎么看呢？

有没有什么好的客户端测试工具？ 目前我正在使用以下 http://code.google.com/p/rest-client/

那么某种客户端代码生成工具呢？

以下链接是我的信息来源。

http://msdn.microsoft.com/en-us/library/dd203052.aspx

http://blogs.msdn.com/b/endpoint/archive/2010/01/07/getting-started-with-wcf-webhttp-services-in-net-4.aspx

【参考方案1】：

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

休息 + 轻量级消息，开销很小（除了 XML 本身） + 易于阅读的结果，可以使用网络浏览器轻松测试 + 易于实施 - 更宽松的界面，宽松的类型检查

肥皂 + 更加严格，具有严格的合同定义 + 大量可用的开发工具。

查看 WCF MSDN 文档，从一开始就集成了 WCF SOAP 支持，而 REST 支持是最近添加的功能。我自己很难找到 REST 服务的身份验证/安全性文档，因为大部分文档都是针对 SOAP 的。

客户端生成工具：我没有遇到任何 REST 服务，因为 REST 没有像 SOAP 那样定义服务契约。 WADL 试图为 REST 服务做到这一点。 http://en.wikipedia.org/wiki/Web_Application_Description_Language http://wadl.codeplex.com/

我有兴趣阅读更多有关身份验证和安全性的回复，因为我自己正在研究。

【讨论】：

这里有一个很好的 WCF 和 REST 介绍：msdn.microsoft.com/en-us/magazine/dd315413.aspx

【参考方案2】：

这是 WCF REST WebService 的一个很好的起点：

REST / SOAP endpoints for a WCF service

（顺便说一句：*** 有很好的 REST 类型的 url。） 您可以仅使用 Web 浏览器测试 REST 服务（转到 url 并获取 XML 或 JSON）。 Fiddler 也是不错的工具，FireFox 的 FireBug-plugin。我通常会制作一个精简的服务接口项目和一个单独的（经过单元测试的）逻辑项目。

对于身份验证，我首先会生成一个 Guid 和一个时间戳。然后基于这些哈希（.NET 支持 SHA256 和 SHA512）。 Guid 可以存储到服务器（数据库表）以映射一些具体的数字 id。然后你可以有一个休息网址，如：

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

并在开发环境中禁用哈希和时间戳检查（例如使用 AOP）。使用时间戳，我会检查时间戳是否在 15 分钟之间及时来回（=应该足以防止攻击）。

您的服务是否对公众/互联网可见？您的客户端是 jQuery 还是 Silverlight 客户端？那么你还有一个问题：你不想在客户端软件代码中包含密钥。

因此，您需要在服务器中生成哈希和某种 cookie 来存储客户端会话。 （这可以通过例如在具有不同配置文件的文件夹中使用单独的登录页面/应用程序来完成。）我记得this book 确实有一些关于该主题的内容：

如果要在使用WCF时启用HttpContext，需要在<system.serviceModel>下设置<serviceHostingEnvironment aspNetCompatibilityEnabled="true">。 然后你可以从HttpContext.Current.User.Identity.Name查看当前用户身份。

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

我认为只使用 LINQ2Xml 或 jQuery 来制作客户端很容易，因此可能不需要生成客户端。

或者您也可以同时拥有 SOAP 和 REST 接口，并使用服务引用来创建客户端。

【讨论】：

一个老问题是“哪个 ID 更好：数字还是 Guid？” Guid 更安全，因为您不能只是猜测它。但数字 id 更清晰、更简单、更干净。如果仅通过数字 id 和时间戳生成散列，则不太安全：毕竟，它们已经破坏了所有主要的散列算法（MD5、SHA）。它们可以生成有效的对称校验和。现在还没有那么快，但也许几年后情况会有所不同。使用此解决方案，您可以获得这两种类型的优势：您无法轻易猜出有效的哈希码，但您不必传输基于 Guid 的 ID。

:) 我的问题不是“guid vs number”。更像是。何时以及由谁在工作流程中生成 guid？

复活和旧主题...当客户端成功提交正确的身份验证时，服务器将生成 guid。它将响应中的 guid/时间戳作为 cookie 发送。

【参考方案3】：

要记住的一件事是，您可以将 REST 视为一种哲学（一切都应该通过一个干净的 URL 访问，没有附加隐藏的字符串）或作为一种教条（您必须使用 PUT 和 DELETE，即使这意味着以后会遇到很多困难）。

重点在于简化——比如对参数使用简单的数据类型而不是结构化的堆积，也不是因为多余的原因而破坏接口（比如在 url 中拖曳巨大的页面“标题”），不使用不为人所知的标题和 de - 事实标准。

因此，您可以仅使用 GET 设计完美的 RESTful 界面，并保留 Web 浏览器的可用性和可测试性。根据您的实际目标受众，您还可以使用任何标准身份验证方法或其中的几种来实现冗余。如果您正在使用标准化的凭据和令牌制作一个在公司网上运行的应用程序，您可以继续使用它。如果您正在做一些非常普遍的访问，您可以使用 GET args 和/或 cookie 的组合 - 为 99.99% 的用户保持您的 URL 干净。

您甚至可以同时提供 JSON 和 XML（例如 Google 地图）并且仍然是 RESTfull，但您不能提供完整的 SOAP（复杂的输入类型等）。您可以执行有限的 SOAP - 请求的简单类型，始终可以表示为 GET 参数，人们仍然可以获得 WSDL 文档。

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