- 用户代理与资源交互,任何可命名和表达的事物都可称为资源。每项资源都有一个唯一的统一资源标识符 (URI)。
- 与资源的交互(通过其唯一的 URI 定位)使用 HTTP 标准动词(GET、POST、PUT 和 DELETE)的统一接口完成。交互中声明资源的媒体类型也很重要,它使用 HTTP 内容类型标头指定。(XHTML、XML、JPG、PNG 和 JSON 就是一些广为人知的媒体类型。)
- 资源是自我描述的。处理资源请求所需的全部信息均包含在请求本身内(这样服务可以没有状态)。
- 资源包含到其他资源的链接(超媒体)。
您为什么应关注 REST?
现在我对 REST 做一些解释,您可能正在想为什么要对它加以关注。作为开发人员,您需要一定的动机来学习和采纳任何风格、技术或模式。如果您阅读此杂志,您可能是常与 Microsoft 技术打交道的开发人员。要实现客户端-服务器应用程序,您可能使用的是另一种体系结构风格:远程过程调用 (RPC)。无论您用过的是专用 RPC 系统(例如 DCOM 或 .NET Remoting),还是可互操作的 RPC 技术(例如,使用 ASMX 或 WCF 的 SOAP),它们都是在 Microsoft 平台上展现的客户端-服务器风格。那么,为什么要学习或使用 REST?
据我所知有两个主要原因。首先,REST 在许多方面所表现出的重要功能和优点都远胜于 RPC 技术。其次,Microsoft 正在将自身许多实现从 RPC 技术(例如 SOAP)转为 REST。这意味着即使您对使用 REST 构建自己的系统尚在犹豫,随着 Microsoft 和其他公司将更多的框架和技术转向 REST,您仍需了解如何与之交互。
以下是一份其他优点的列表(并非全部优点都已列出):
缓存 使用 HTTP 向 RESTful 端点申请数据时,用到的 HTTP 动词是 GET。对于 GET 请求响应中返回的资源,可以用多种不同的方式进行缓存。Conditional GET 就是可供选择的一种实现细节,客户端可以向服务验证他的数据是否为最新版本;RESTful 端点可以通过它进一步提高速度和可伸缩性。
扩展 REST 鼓励每项资源包含处理特殊请求所需的所有必要状态。满足这一约束时,RESTful 服务更易于扩展且可以没有状态。
副作用如您使用 GET 请求资源,RESTful 服务应该没有副作用(遗憾的是,与其他一些 REST 约束相比,这一约束更容易被打破)。
幂等 统一接口另外两个常用到的主要 HTTP 动词是 PUT 和 DELETE。用户代理想要修改资源时最常使用 PUT,DELETE 可以自我描述。要点(也就是“幂等”一词所强调的)是您可以对特殊资源多次使用这两个动词,效果与首次使用一样——至少不会有任何其他影响。构建可靠的分布式系统时(即错误、网络故障或延迟可能导致多次执行代码),这一优点可提供保障。
互操作性 许多人将 SOAP 捧为建立客户端-服务器程序最具互操作性的方法。但一些语言和环境至今仍没有 SOAP 工具包。有一些虽然有工具包,但采用的是旧标准,不能保证与使用更新标准的工具包可靠沟通。对于大多数操作,REST 仅要求有 HTTP 库(当然,XML 库通常也很有帮助),它的互操作性肯定强过任何 RCP 技术(包括 SOAP)。
简易性与其他优点相比,这一优点更主观一些,不同的人可能有不同的感受。对我而言,使用 REST 的简易性涉及到代表资源的 URI 和统一接口。作为一名 Web 冲浪高手,我理解在浏览器中输入不同的 URI 可以得到不同的资源(有时也被称为 URI 或 URL 黑客,但绝无恶意)。由于有多年使用 URI 的经验,所以为资源设计 URI 对我来说得心应手。使用统一接口简化了开发过程,因为我不必为每个需要建立的服务构建接口、约定或 API。接口(客户端与我的服务交互的方式)由体系结构约束设置。
正如我所说的,这并不是一份详尽的列表,您也不能因此认定 REST 是唯一一种经常使用的技术。您应该了解的是它的长处,以便在需要时能够加以利用。
目前,wcf也可以通过以下新特性完成restful功能架构
编程模型有两个主要的新属性:WebGetAttribute 和 WebInvokeAttribute;还有一个 URI 模板机制,帮助您声明每种方法响应用的 URI 和动词。基础架构的组成是一个绑定 (WebHttpBinding) 和一种行为 (WebHttpBehavior),为使用 REST 提供适宜的连网堆栈。此外,自定义的 ServiceHost (WebServiceHost) 和 ServiceHostFactory (WebServiceHostFactory) 还提供了一些托管基础架构方面的帮助。