REST

 

本文永久链接 http://blog.csdn.net/hereweare2009/archive/2009/08/26/4487940.aspx

一、REST的基本思想

[Fielding]把REST形式化地定义为一种架构风格（architecture style），它由架构元素（element）和架构约束（constraint）组成。REST是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。REST提出了一些设计概念和准则：

1.         网络上的所有事物都被抽象为资源（resource）；

2.         每个资源对应一个唯一的资源标识（resource identifier）；

3.         通过通用的连接器接口（generic connector interface）对资源进行操作；

4.         对资源的各种操作不会改变资源标识；

5.         所有的操作都是无状态的（stateless）。

对于当今最常见的网络应用来说，resource identifier是url，generic connector interface是HTTP，第4条准则就是我们常说的url不变性。这些概念中的resouce最容易使人产生误解。resouce所指的并不是数据，而是数据+特定的表现形式（representation），这也是为什么REST的全名是Representational State Transfer的原因。举个例子来说，“本月卖得最好的10本书”和“你最喜欢的10本书”在数据上可能有重叠（有一本书即卖得好，你又喜欢），甚至完全相同。但是它们的representation不同，因此是不同的resource。

在web上，你能对资源采取的仅限于一些基本的操作。HTTP提供了四种基本方法，用于四种最常见的操作：

1.       获取资源的一个表示：HTTP GET

2.       创建一个新资源：向一个新URI发送HTTP PUT，或者向一个已有URI发送HTTP POST.( PUT请求是由客户端决定（被创建或更新的）资源的URI；而POST请求是向一个“集合（collection）”或 “工厂（factory）”资源发出的，是由服务器来指派URI的。)

3.       修改已有资源：向已有URI发送HTTP PUT

4.       删除已有资源：HTTP DELETE

 

二、REST式、面向资源的架构

REST式的架构意味着方法信息method information都在HTTP方法（如GET，POST等，默认的HTTP方法是GET）里，方法信息就是关于对数据采取什么操作的信息，即Server端提供的业务方法，不能出现在URI里；面向资源的架构Resource-Oriented Architecture意味着作用域信息scoping information都在URI里，作用域信息可以理解为业务方法所需的一组参数。将二者结合起来是很强大的，即REST式、面向资源的架构。实际上很多HTTP请求的第一行就能让Server端知道客户端要做什么了，请求的其余部分只是具体细节而已。如果HTTP方法跟方法信息对不上，那么服务就算不上是REST式的；如果作用域信息不放在URI里，那么这项服务不是面向资源的。

 

三、RPC式架构

       RPC式的web服务通常是Server端从客户端收到一个充满数据的信封envelope，信封里或者报头包含客户端请求的方法信息与作用域信息，Server端处理请求后，同样发给客户端一个充满信息的信封。RPC式的架构意味着方法信息与作用域信息都在信封或者报头里。具体采用哪种信封，没有限制。HTTP是一种常见的信封格式，另一种常见的信封格式是SOAP，将SOAP信封放在HTTP信封里，在HTTP上传送SOAP文档。XML-RPC是最典型的RPC架构的例子。下面是一段描述XML-RPC请求的XML文档：

<?xml version=”1.0”>

<methodCall>

<methodName>lookupRPC</methodName>

<params>

<param><value><string>jfksajfksajfs</string></value></param>

</params>

</methodCall>

这个XML文档是放在信封里传递给服务器的，这里的信封就是HTTP请求，它由HTTP方法，URI，包头和实体主体等部分组成，其中实体主题就是上面的xml文档。上面的XML文档随你调用方法的不同而有所变化，只是HTTP信封格式总是不变的，即URI与HTTP方法 POST是不变的，只是信封主体的XML文档的methodName与params有变化。REST式的服务为不同的作用域信息暴露不同的URI；而RPC式的服务为每个“文档处理器”（用于打开信封，并把信封转化为软件指令）暴露一个URI。

较多的采用或者只采用HTTP POST的服务多半是RPC式的服务。虽然这不是绝对的，但是至少可以说明该服务没有把HTTP方法用于表达方法信息。如果一个REST式的服务过多地采用HTTP POST，那么他容易变成REST-RPC混合架构。

 

四、REST-RPC混合架构

       看这个URI：

http://www.myserver.com/services/rest?api_key=xxx&method=myserver.item.get&tags=book

虽然这个URI包含着rest字样，但是它把方法信息myserver.item.get放在了URI里了，这说明它不是采用rest式的架构了；但是作用域信息却包含在URI里了，这跟REST式、面向资源的架构有点类似了。该URI的HTTP请求为：

GET services/rest? api_key=xxx&method=myserver.item.get&tags=book HTTP/1.1

HOST:www.myserver.com

看上去好像确实是REST式的服务，方法信息和作用域信息都在头部，没有在实体主体中。这些RPC式的服务，不经意间或多或少的带着点REST式的web服务的特征。他们只是把HTTP作为一种信封格式来用，不过他们使用HTTP信封的方式可能跟REST式的服务的做法雷同。

许多的只读的web服务，尽管他们起初也许是按RPC风格来设计的，但可称得上是完全的REST式和面向资源的，但是，如果该服务允许客户端修改资源的话，就会出现客户端所使用的HTTP方法与真正的方法信息不一致的情况，这样就不具备REST式服务的特征，我们称这类服务为REST-RPC混合服务。

       总之，对于一个REST式的web服务，它会在HTTP方法里（HTTP请求的第一行）寻找方法信息，在URI里寻找方法的作用域信息；而RPC式的Web服务则往往忽略HTTP方法，在URI、HTTP报头或者实体主体里寻找方法信息与作用域信息。有些RPC式的web服务把HTTP作为一种容纳文档的信封，而另一些RPC式的web服务则把HTTP作为一种容纳另一个信封的信封；一个REST式的面向资源的服务为客户端可能操作的每一则数据暴露一个URI；一个REST-RPC混合服务为客户端可能进行的每一个操作暴露一个URI（比如获取数据用一个URI，修改数据用另一个URI）；一个RPC式服务为每个处理远程调用的进程暴露一个URI。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/hereweare2009/archive/2009/08/26/4487940.aspx

转载于:https://www.cnblogs.com/sardine/archive/2010/09/01/1814522.html