热门Web开发方式 REST实现原理浅析

日期: 2009-11-23 作者:51CTO 来源:TechTarget中国 英文

  REST首先只是一种架构样式,不是一种标准。这点和Ajax类似,两者都是利用现有的成熟技术。在REST的定义中,一个Web应用总是使用固定的URI向外部世界呈现(或者说暴露)一个资源。

  注:URI是英文Uniform Resource Identifier的缩写,中文翻译“通用资源标志符”。“通用资源标志符”是指唯一标识一个资源(xhtml文件、图片、css样式表)的字符串。当然了,RFC中定义的URI复杂得多,不过我们此处将 URI 想象成一个人的身份证号码就行了(你不能有两个同时有效的身份证号码,一个号码也不可能同时对应两个人)。而我们天天挂在嘴边的 URL 地址就是URI的一种表现形式(个人理解,有错请纠正)。

  知道什么是URI后,我们来看一个实际例子:

  http://www.example.com/photo/logo指向example.com网站(可以视为一个Web应用)中类型为photo,名字为logo的资源。我们用浏览器访问这个URI,看到的将可能是一个xhtml文档,其中用<img src=”……” />来显示实际的照片。

  http://www.example.com/photo/logo很容易让你想到URL重写。事实上,这个地址很可能会在服务器内部处理为 http://www.example.com/photo.php?name=logo这样的地址。photo.php是服务器端的一个动态脚本文件,根据name参数生成xhtml文档返回给浏览器。

  现在假设我们要获取这张照片的XML文档。XML文档中包含照片的文件名、文件大小、拍摄日期等等信息。也就是说我们要获取“同一个资源的不同表现形式的数据”。对于这个要求,我们可以很容易的用另一个URL地址达到:http://www.example.com/xml/logo。

  但是,这就违背了“URI唯一标识一个资源”的定义。如果我们要获取同一个资源的多种表现形式,那么就要使用更多的URL,从而给一个资源指定了多个不同的URI。

  而在REST中,不管是获取照片的xhtml文档还是XML文档,或者照片文件本身,都是用同一个URI,就是 http://www.example.com/photo/logo。

  那这是怎么办到的呢?Ruby On Rails中是通过分辨HTTP Request Header信息来分辨客户端是想要取得资源的哪一种表现形式的数据。

  当我们用浏览器访问一个网址时,浏览器会构造一个HTTP请求。这个请求有一个头信息,其中包括了本次请求接受何种类型的数据。通常浏览器发送的HTTP请求头中,Accept的值都是 */*,也就说接受服务器返回的任何类型的数据。

    看到这里,聪明的家伙应该知道了。只要我们指定一个特定的Accept参数,那么服务器就可以通过判断该参数来决定返回什么类型的数据。所以在一个采用REST架构的应用中,要获取同一个资源的不同表现形式的数据,只需要使用不同的HTTP请求头信息就行了。

  如果考虑为Web应用增加Web Services,这种技术的价值就体现出来了。比如我写了一个Delphi程序,现在只需要构造一个包含Accept: text/xml的HTTP请求头,然后将请求发送到http://www.example.com/photo/logo就可以了。返回的结果就是一个XML文档,而不是xhtml文档。

  因为我们的HTTP请求头信息有不同的状态,从而可以获得不同的数据,所以叫做“具象状态传输” 。

  除了上面的用法,REST还有进一步的扩展。

  我们在Web应用中处理来自客户端的请求时,通常只考虑GET和POST这两种HTTP请求方法。实际上,HTTP还有HEAD、PUT、DELETE等请求方法。而在REST架构中,用不同的HTTP请求方法来处理对资源的CRUD(创建、读取、更新和删除)操作:

  ◆POST: 创建
  ◆GET: 读取
  ◆PUT: 更新
  ◆DELETE: 删除

  经过这样的一番扩展,我们对一个资源的CRUD作就可以通过同一个URI完成了:

  http://www.example.com/photo/logo(读取)

   仍然保持为[GET] http://www.example.com/photo/logo

http://www.example.com/photo/logo/create (创建)

  改为[POST] http://www.example.com/photo/logo

  http://www.example.com/photo/logo/update(更新)

  改为[PUT] http://www.example.com/photo/logo

  http://www.example.com/photo/logo/delete(删除)

  改为[DELETE] http://www.example.com/photo/logo

  从而进一步规范了资源标识的使用。

  通过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,而不是通过浏览器操作的应用程序。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐

  • API开发与管理大作战

    2014将会是API管理方法新旧PK的一年,据Delyn Simons说,她领导了Mashery开发者的外展团队。应用编程接口(API)的主流化和私有化在新的一年也将掀起波澜,她在波士顿“Future Insights Ultimate Developer Event 2013”大会上预测说。

  • 公共API外包管理是否值得考虑?

    公共API外包管理是指聘请一个专家小组来解决可扩展性问题,同时也提出几套可替代的方案。

  • 最适合大数据应用的是SOA还是REST?

    跟所有的企业数据一样,大数据唯有通过应用投射给用户才有用。对于设计或重新设计大数据应用的架构师来说,一个关键问题是究竟是用SOA还是RESTful的API?

  • 弹性资源对传统的REST架构构成挑战了吗?

    组件化应用程序需要机制来将组件传递到下一个工作地。从一开始,人们对连接流程及其实施就有不同的观点。可以证明,SOA阵营是由RPC和SOAP的软件接口发展而形成的。