基于REST风格的远程调用



表象化状态转变(英文:Representational State Transfer,简称REST)是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。

目前在三种主流的Web服务实现方案中,因为REST模式的Web服务与复杂的SOAP和XML-RPC对比来讲明显的更加简洁,越来越多的web服务开始采用REST风格设计和实现。例如,Amazon.com提供接近REST风格的Web服务进行图书查找;雅虎提供的Web服务也是REST风格的。国内的,taobao等都使用了这种REST风格远程调用(top,淘宝接口)。

REST 从资源的角度来观察整个网络,分布在各处的资源由URI确定,而客户端的应用通过URI来获取资源的表形。获得这些表形致使这些应用程序转变了其状态。随着不断获取资源的表形,客户端应用不断地在转变着其状态,所谓表形化的状态转变(Representational State Transfer)。

这一观点不是凭空臆造的,而是通过观察当前Web互联网的运作方式而抽象出来的。Roy Fielding 认为,设计良好的网络应用表现为一系列的网页,这些网页可以看作的虚拟的状态机,用户选择这些链接导致下一网页传输到用户端展现给使用的人,而这正代表了状态的转变。

需要注意的是,REST是设计风格而不是标准。REST通常基于使用HTTP,URI,和XML以及HTML,json这些现有的广泛流行的协议和标准。

包括如下标准
1.资源是由URI来指定。(http://127.0.0.1/rest?service=test&id=1)。
2.对资源的操作包括获取、创建、修改和删除资源,这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。
3.通过操作资源的表形来操作资源。如对于{result:success}对客户端来说,这个返回的表形就是成功了。
4.源的表现形式则是XML或者HTML又或者json,取决于读者是机器还是人,是消费web服务的客户软件还是web浏览器。当然也可以是任何其他的格式。

REST的要求
1.客户端和服务器结构,调用者就是客户端了。
2.连接协议具有无状态性。
3.能够利用Cache机制增进性能。
4.层次化的系统。
5.随需代码 - Javascript (可选),又或者java,又或者C#都可以。

关于状态
应该注意区别应用的状态和连接协议的状态。REST对于连接的无状态性实际上要求每次经过无状态的连接协议传送的信息必须包含应用中所有的状态信息。(这句话没理解)

基于web的REST
RESTful Web 服务
RESTful Web 服务(也称为 RESTful Web API)是一个使用HTTP并遵循REST原则的Web服务。它从以下三个方面资源进行定义:

URI,比如:http://example.com/resources/。
Web服务接受与返回的互联网媒体类型,比如:JSON,XML ,YAML 等。
Web服务在该资源上所支持的一系列请求方法(比如:POST,GET,PUT或DELETE)。

资源 GET PUT POST DELETE
一组资源的URI,比如http://127.0.0.1.com/user/ 列出资源组中的每个资源的URI,以及该资源组中每个资源的详细信息(后者可选)。这里安装标准标准应该是列出每个user的详细信息的uri,资源详细信息(详细信息可以忽略) 使用给定的一组资源替换当前整组资源。类似与批量修改 在本组资源中创建/追加一个新的资源。 该操作往往返回新资源的URL。如http://127.0.0.1.com/user/liyixing/xingxinga 我们需要添加一个新的用户到当前返这个用户列表中,这个用户是liyixing,密码是xingxinga。返回的是成功(success),已经访问详细的uri http://127.0.0.1.com/user/123 123是id号。 删除 整组资源。类似批量删除
http://127.0.0.1.com/user/123 获取 指定的资源的详细信息,格式可以自选一个合适的网络媒体类型(比如:XML、JSON等)这里我们应该列出这个id为123的用户的详细 替换/创建 指定的资源。并将其追加到相应的资源组中。如果是替换,无需特殊处理,需要返回success。如果是追加,需要返回新的资源的uri 把指定的资源当做一个资源组,并在其下创建/追加一个新的元素,使其隶属于当前资源。这个时候这个资源就会成为一个资源组而不是一个资源详细了。如 http://127.0.0.1.com/user/123本来只是一个用户。但是post之后http://127.0.0.1.com/user/123 添加了一个子用户,liyixing1,xingxinga,那么这个用户就同时资源组合资源详细了。 删除这个资源



幂等方法
假如在不考虑诸如错误或者过期等问题的情况下,若干次请求的副作用与单次请求相同或者根本没有副作用,那么这些请求方法就能够被视作“幂等”的。GET,HEAD,PUT和DELETE方法都有这样的幂等属性,同样由于根据协议,OPTIONS,TRACE都不应有副作用,因此也理所当然也是幂等的。

假如某个由若干个请求做成的请求串行产生的结果在重复执行这个请求串行或者其中任何一个或多个请求后仍没有发生变化,则这个请求串行便是“幂等”的。但是,可能出现若干个请求做成的请求串行是“非幂等”的,即使这个请求串行中所有执行的请求方法都是幂等的。例如,这个请求串行的结果依赖于某个会在下次执行这个串行的过程中被修改的变量。



PUT 和 DELETE 方法是幂等方法。GET方法是安全方法 (不会对服务器端有修改,因为不会修改,只是get数据,所以每次返回的结果因此一样的,除非你还返回了随机数或者当前时间,因此也是幂等的)。

不像基于SOAP的Web服务,RESTful Web服务并没有的“正式”标准[2]。 这是因为REST是一种架构,而SOAP只是一个协议。虽然REST不是一个标准,但在实现RESTful Web服务时可以使用其他各种标准(比如HTTP,URL,XML,PNG等)。

[编辑]实现举例
例如,一个简单的网络商店应用,

列举所有商品,

GET http://www.store.com/products

具体某一件商品,

GET http://www.store.com/product/12345

下单购买,

POST http://www.store.com/order

<purchase-order>
  <item> ... </item>
</purchase-order>

REST的优点

可以利用缓存Cache来提高响应速度
通讯本身的无状态性可以让不同的服务器的处理一系列请求中的不同请求,提高服务器的扩展性
浏览器即可作为客户端,简化软件需求
相对于其他叠加在HTTP协议之上的机制,REST的软件依赖性更小
不需要额外的资源发现机制
在软件技术演进中的长期的兼容性更好

你可能感兴趣的:(应用服务器,REST,网络协议,网络应用,Restful)