转REST框架介绍

学习 REST REST 是由 Roy Fielding 在他的论文 《Architectural Styles and the Design of Network-based Software Architectures》中提出的一个术语。 REST 是英文 Representational State Transfer 的缩写，有中文翻译为“具象状态传输”（参考： 《SIP/IMS网络中的Representational State Transfer (REST)和数据分布》）。 ————————————— 前面的内容比较枯燥，我说说我自己的理解。 但是 REST 到底是什么呢？论文我看不懂，不过找到一篇更简单易懂的东西： 《Building Web Services the REST Way》。 根据这篇文章，我整理了一下我自己对 REST 的理解： REST 首先只是一种架构样式，不是一种标准。这点和 Ajax 类似，两者都是利用现有的成熟技术。 在 REST 的定义中，一个 Web 应用总是 使用固定的 URI 向外部世界呈现（或者说暴露）一个资源。 URI 是英文 Uniform Resource Identifier 的缩写，中文翻译“通用资源标志符”。 “通用资源标志符”是指 唯一标识一个资源（xhtml 文件、图片、css 样式表）的字符串。当然了，RFC 中定义的 URI 复杂得多，不过我们此处将 URI 想象成一个人的身份证号码就行了（你不能有两个同时有效的身份证号码，一个号码也不可能同时对应两个人）。而我们天天挂在嘴边的 URL 地址就是 URI 的一种表现形式（个人理解，有错请纠正）。 知道什么是 URI 后，我们来看一个实际例子： [url]http://www.example.com/photo/logo[/url] 指向 example.com 网站（可以视为一个 Web 应用）中类型为 photo，名字为 logo 的资源。我们用浏览器访问这个 URI，看到的将可能是一个 xhtml 文档，其中用 <img src=”……” /> 来显示实际的照片。 [url]http://www.example.com/photo/logo[/url] 很容易让你想到 URL 重写。事实上，这个地址很可能会在服务器内部处理为 [url]http://www.example.com/photo.php?name=logo[/url] 这样的地址。photo.php 是服务器端的一个动态脚本文件，根据 name 参数生成 xhtml 文档返回给浏览器。 现在假设我们要获取这张照片的 XML 文档。XML 文档中包含照片的文件名、文件大小、拍摄日期等等信息。也就是说我们要获取 “同一个资源的不同表现形式的数据”。对于这个要求，我们可以很容易的用另一个 URL 地址达到：[url]http://www.example.com/xml/logo[/url]。 但是，这就违背了 “URI 唯一标识一个资源”的定义。如果我们要获取同一个资源的多种表现形式，那么就要使用更多的 URL，从而给一个资源指定了多个不同的 URI。 而在 REST 中，不管是获取照片的 xhtml 文档还是 XML 文档，或者照片文件本身，都是用同一个 URI，就是 [url]http://www.example.com/photo/logo[/url]。 那这是怎么办到的呢？Ruby On Rails 中是通过分辨 HTTP Request Header 信息来分辨客户端是想要取得资源的哪一种表现形式的数据。 当我们用浏览器访问一个网址时，浏览器会构造一个 HTTP 请求。这个请求有一个头信息，其中包括了本次请求接受何种类型的数据。通常浏览器发送的 HTTP 请求头中，Accept 的值都是 */*，也就说接受服务器返回的任何类型的数据。 看到这里，聪明的家伙应该知道了。只要我们指定一个特定的 Accept 参数，那么服务器就可以通过判断该参数来决定返回什么类型的数据。所以在一个采用 REST 架构的应用中，要获取同一个资源的不同表现形式的数据，只需要使用不同的 HTTP 请求头信息就行了。 如果考虑为 Web 应用增加 Web Services，这种技术的价值就体现出来了。比如我写了一个 Delphi 程序，现在只需要构造一个包含 Accept: text/xml 的 HTTP 请求头，然后将请求发送到 [url]http://www.example.com/photo/logo[/url] 就可以了。返回的结果就是一个 XML 文档，而不是 xhtml 文档。 因为我们的 HTTP 请求头信息有不同的状态，从而可以获得不同的数据，所以叫做“具象状态传输” :) ————————————— 除了上面的用法，REST 还有进一步的扩展。 我们在 Web 应用中处理来自客户端的请求时，通常只考虑 GET 和 POST 这两种 HTTP 请求方法。实际上，HTTP 还有 HEAD、PUT、DELETE 等请求方法。而在 REST 架构中，用不同的 HTTP 请求方法来处理对资源的 CRUD（创建、读取、更新和删除）操作： POST: 创建 GET: 读取 PUT: 更新 DELETE: 删除 经过这样的一番扩展，我们对一个资源的 CRUD 操作就可以通过同一个 URI 完成了： [url]http://www.example.com/photo/logo[/url]（读取） 仍然保持为 [GET] [url]http://www.example.com/photo/logo[/url] [url]http://www.example.com/photo/logo/create[/url]（创建） 改为 [POST] [url]http://www.example.com/photo/logo[/url] [url]http://www.example.com/photo/logo/update[/url]（更新） 改为 [PUT] [url]http://www.example.com/photo/logo[/url] [url]http://www.example.com/photo/logo/delete[/url]（删除） 改为 [DELETE] [url]http://www.example.com/photo/logo[/url] 从而进一步规范了资源标识的使用。 通过 REST 架构，Web 应用程序可以用一致的接口（URI）暴露资源给外部世界，并提供对资源的操作服务。这对于以资源为中心的 Web 应用来说非常重要。例如照片共享网站、用户社区等。 ————————————— Ruby On Rails 1.2 版对 REST 有很好的支持，但要在 PHP 中应用 REST 还需要解决不少问题： 如何在服务端判断 PUT、DELETE 请求方法； 如何获取用 PUT、DELETE 请求方法中传递的数据； 如何获取 HTTP 请求头信息中的 Accept 参数值； 如何在浏览器端发起 PUT 和 DELETE 请求。 不过我仔细看了 PHP 文档，我觉得上面几个问题都是可以解决的。 服务端综合使用 $_SERVER[’HTTP_ACCEPT’]、$_SERVER[’REQUEST_URI’]、$_SERVER [’REQUEST_METHOD’]、$_SERVER[’QUERY_STRING’] 这些变量应该可以搞定前面三个问题。而第四个问题则可以用 JavaScript 的 XMLHttpRequest 对象来实现。 不过我想 REST 的真正价值在于 Web Services，而不是通过浏览器操作的应用程序。

本文转自 fsjoy1983 51CTO博客，原文链接：http://blog.51cto.com/fsjoy/76918，如需转载请自行联系原作者