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原则的。

    应用状态的转移

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

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

你可能感兴趣的:(restful,架构,后端)