Restful架构简单了解

Restful

Rest全称representational status transfer 表述性状态转移。

原则

• 资源与URI

  URI既可以看成是资源的地址，也可以看成是资源的名称。如果某些信息没有使用URI来表示，那它就不能算是一个资源， 只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则，具有自描述性，需要在形式上给人以直觉上的关联。

• 统一资源接口

  RESTful架构应该遵循统一接口原则，统一接口包含了一组受限的预定义的操作，不论什么样的资源，都是通过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GET，PUT和POST，并遵循这些方法的语义。

  如果按照HTTP方法的语义来暴露资源，那么接口将会拥有安全性和幂等性的特性，例如GET和HEAD请求都是安全的， 无论请求多少次，都不会改变服务器状态。而GET、HEAD、PUT和DELETE请求都是幂等的，无论对资源操作多少次， 结果总是一样的，后面的请求并不会产生比第一次更多的影响。

• 资源表述

  资源在外界的具体呈现，可以有多种表述(或成为表现、表示)形式，在客户端和服务端之间传送的也是资源的表述，而不是资源本身。 例如文本资源可以采用html、xml、json等格式，图片可以使用PNG或JPG展现出来。

  资源的表述包括数据和描述数据的元数据，例如，HTTP头"Content-Type" 就是这样一个元数据属性。

  客户端可以通过HTTP内容协商，客户端通过Accept头请求一种特定格式的表述，服务端则通过Content-Type告诉客户端资源的表述形式。

• 资源的链接

  从一个连接跳到一个页面，再从另一个连接跳到另外一个页面，把一个个把资源链接起来。

  表现形式：在响应体里加入要跳转的资源的uri。

• 状态转移

  REST原则为无状态通信原则。

  无状态通信原则，并不是说客户端应用不能有状态，而是指服务端不应该保存客户端状态。

  应用状态与资源状态：

  状态应该区分应用状态和资源状态，客户端负责维护应用状态，而服务端维护资源状态。

  客户端与服务端的交互必须是无状态的，并在每一次请求中包含处理该请求所需的一切信息。

  服务端不需要在请求间保留应用状态，只有在接受到实际请求的时候，服务端才会关注应用状态。

  这种无状态通信原则，使得服务端和中介能够理解独立的请求和响应。

  在多次请求中，同一客户端也不再需要依赖于同一服务器，方便实现高可扩展和高可用性的服务端。

  但有时候会做出违反无状态通信原则的设计，例如利用Cookie跟踪某个服务端会话状态，常见的像J2EE里边的JSESSIONID。

  这意味着，浏览器随各次请求发出去的Cookie是被用于构建会话状态的。

  当然，如果Cookie保存的是一些服务器不依赖于会话状态即可验证的信息（比如认证令牌），这样的Cookie也是符合REST原则的。

  应用状态的转移：

  "会话"状态不是作为资源状态保存在服务端的，而是被客户端作为应用状态进行跟踪的。客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入。

  这些类似"下一页"之类的链接起的就是这种推进状态的作用——指引你如何从当前状态进入下一个可能的状态。