潍坊专业网站建设公司,万能素材网站下载,电商平台投诉,漫画网站开发说明Restful
Rest全称representational status transfer 表述性状态转移。
原则 资源与URI URI既可以看成是资源的地址#xff0c;也可以看成是资源的名称。如果某些信息没有使用URI来表示#xff0c;那它就不能算是一个资源#xff0c; 只能算是资源的一些信息而已。URI的设计…Restful
Rest全称representational status transfer 表述性状态转移。
原则 资源与URI URI既可以看成是资源的地址也可以看成是资源的名称。如果某些信息没有使用URI来表示那它就不能算是一个资源 只能算是资源的一些信息而已。URI的设计应该遵循可寻址性原则具有自描述性需要在形式上给人以直觉上的关联。 统一资源接口 RESTful架构应该遵循统一接口原则统一接口包含了一组受限的预定义的操作不论什么样的资源都是通过使用相同的接口进行资源的访问。接口应该使用标准的HTTP方法如GETPUT和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原则的。 应用状态的转移 会话状态不是作为资源状态保存在服务端的而是被客户端作为应用状态进行跟踪的。客户端应用状态在服务端提供的超媒体的指引下发生变迁。服务端通过超媒体告诉客户端当前状态有哪些后续状态可以进入。 这些类似下一页之类的链接起的就是这种推进状态的作用——指引你如何从当前状态进入下一个可能的状态。
