【原创】RESTful Web Services(一)

 

<span style='color:red;'>【原创】</span>RESTful Web Services(一)

SeeleCloud·Ramostear

前言:学些web的知识点,不得不说一下HTTP协议,虽然它不是最好的web协议,它有着许多让人诟病的不足,但是它依然特别适合分布式Internet应用的。它看起来没有值得一提的特性,很简单,但是正是因为它的简单,转化成了强大的能力。

 

一 面向资源架构的基础

Resource-Oriented Architecture Basic 

 

Web服务和网站的根本不同之处在于:用户(Web服务的用户是预先编辑好的客户端,而不是人)与客户端能力,Web服务和网站都受益于HTTPURIXML的面向资源的设计(Resource-Oriented Design)。

在你的Web应用管理之下的任何有价值的事物,都应该被暴露为一个资源(resource)。任何可以被客户端所链接到的事物,都是一个资源。例如:一张图片、一个字符、一段视频/音频,一个地址等等。

URI是每一个资源所对应的名称,一个资源必须至少有一个或者多个资源名称,但是对于一个资源来说,它对应的URI名称越少越好,而且每一个资源的URI名称都应该具有一定的意义。

总所周知,客户端是无法直接获取一个资源的,它只能获取该资源的一个表示(representations)—具有特定数据格式、包含关于该资源信息的文档。对于网站而言,资源(resource)就是被按原样传递个客户端的文件—txthtmlxml等文件。访问资源则是通过HTTP统一的接口进行的:即四个基本的HTTP方法:GET(获取)、POST(提交)、PUT(修改)和DELETE(删除),另外还有两个辅助的方法HEADOPTIONS。值得一提的是,资源,资源的表示,以及资源之间的相互链接,他们可以是复杂的,但是访问的方法必须的简单的。

 

二 一般的ROA设计步骤

The Generic ROA Procedure

ROAResource-Oriented Architecture (面向资源架构)的简称,一般的ROA设计步骤,需要考虑到RESETROA的约束,大致的步骤如下:

1.规划数据集

2.把数据划分为资源,对其中的每一种资源进行命名

3.URI为该资源命名

4.暴露一个统一接口的子集

5.设计来自客户端的表示

6.设计发送给客户端的表示

7.用超链接和表单把该资源与已有资源联系起来

8.考虑有哪些基本的或者经典的事件经过

9.考虑可能出现哪些错误情况(标准的控制流在这里同样会有所帮助)

 

三 可寻址性

Addressability

可寻址性是相对于一个Web应用程序或者一个Web服务来说的。如果一个Web服务或者一个Web应用程序将其数据集里的数据作为资源暴露出来,那么对于该运用就是可寻址的(address ability)。在说明可寻址性之前,应该再次解释一下URIURIUniversal Resource Identifier (“统一资源标识符”)的缩写,对于Web应用而言,每一个资源都具有唯一的URI,但是对于REST式的Web服务而言,它们所暴露的URI有一个或者多个,这里简称为URIs;在RPCRemote Procedure Call(“远程过程调用”)式的Web服务中,它们暴露的URI数量很少,通常情况下都只有一个。

 

四 表示的可寻址性

Representation IS Addressability

在可寻址性中说到一个资源可以有一个或者多个URI,但是对于一个URI,它必须只对应一个资源,否则它就不是统一资源标示了。与此同时,对于一个资源的不同标示,应该具有不同的URI,应为URI通常要被请求和相应进行传输,或者作为其他Web服务的输入,所以一个URI应该标识一个资源的特定标识。

例如你的一个Web运用中用“/article/100”这个URI来暴露一篇文章,但是该文章要分为中文和英文版,还需要分为HTML和纯文本版。如果按照RPC式的Web服务,需要设置客户端的Accept-Language请求报头,还需要设置Accept请求报头在HTML和纯文本之间进行选择,但是现在通过RESET式的服务,你只需要为每一个表示独立分配一个URI即可,比如用“/article/100/zh-cn.html”、“/article/100/zh-cn.txt”、“/article/100/en-us.html”和“article/100/en-us.txt”来完成上述的需求。

这样做的好处是,当一个Web服务的客户端需要向该URI请求这篇文章而没有特定的要求是,你就可以通过“/article/100”这个URI告知客户端,如果一个Web服务的客户端需要引用此文章特定语言或者特定格式的版本时,就可以用特定的URI来告知客户端。

客户端用HTTP请求报头来发送信息,这是可以的,只要服务器不是仅仅靠其中的信息来选择资源或者表示就可以。报头里面也可以包含一些敏感的信息,如认证的证书等。但是报头不应该是唯一“被客户端用来指定请求哪一种资源或表示”的地方。

 

五 状态与无状态性

State And Statelessness

REST式的Web服务里,在谈论状态性和无状态性之前,需要弄清楚两个概念,资源状态和应用状态,以及两者之间的转化关系。

资源状态是指关于资源的所有信息,应用状态是指关于客户端在应用中所处状态的信息。资源状态(resource state)是保存在Web服务端的,它只以representation(“表示”)的形式发送给客户端。应用状态(application state)保存在客户端里;它通常被用在创建、修改或者删除一个资源时,将它作为POSTPUT或者DELETE请求的一部分发送给服务器,成为资源状态,应用状态和资源状态之间的关系如资源-应用状态转换图所示:

.

 

当一个REST式的Web服务从来不保存任何应用的状态,那么就称这个REST式的Web服务为“无状态的(stateless)”。在一个无状态的应用里,服务是按照当前资源状态来独立处理各个客户端请求的,在这样的情况下,如果客户端需要附带一些其他的状态信息,就需要在请求的报头中把这些附带的信息加上,作为请求信息的一部分,发送给服务端。

 

六 统一接口

The Uniform Interface

客户端和资源的所有交互,都是通过HTTP的几个基本方法进行的,任何资源都需要暴露这些方法的一个子集出来,而且这些方法无论被那个资源所暴露,都具有相同的意义。

GET请求用于获取关于资源的相关信息。这些信息将以报头(headers)和表示(representation)的形式返回给客户端。客户端在发送GET请求时,不需要提供表示(representation)。HEAD请求和GET请求没有多大的差别,唯一不同的地方在于HEAD请求只返回报头,不返回表示(representation),而GET请求需要返回表示(representation)。PUT请求用于设定资源的状态。客户端通常会在发送PUT请求时提供一个表示,服务器将根据此表示(representation)来创建或修改资源的状态。DELETE请求用于删除资源。在客户端发送DELETE请求时无需向服务器提供表示(representation)。POST请求的作用则在于为已经存在的资源创建一个从属资源(subordinate resource)。POST请求除了用于新建一个资源外,还可以用于往已有资源的状态里添加数据。OPTIONS请求用于查询一个资源支持统一接口里的哪些方法(例如采用什么格式回显)。

----------------------------------------------------------------------

未完待续.....................

----------------------------------------------------------------------