RESTful三理解

目录

前言

最近看了一篇很赞的RESTful博客,传送门:http://www.cnblogs.com/artech/p/3506553.html

本篇是RESTful的又一次理解笔记,将之前写过的文章做一个总结和消化,应该是关于RESTful的最后一篇基础理论文章,之后会向实践倾斜,通过编写Python RESTful API来更好的消化理论。

本篇继续探究为什么会将这种Web Service设计风格命名为RESTful(REpresentational State Transfer 表现层状态转化)

在解决这个问题之前,首先需要认识几个概念。

Web应用的会话状态

会话(Session):指Client浏览器和Web Server之间连续发生的一系列请求个响应过程。

会话状态:指Client浏览器与Web Server在会话过程中产生的状态信息,这些状态信息是Web Server能够把属于同一个会话中的一系列请求和响应关联起来。

会话跟踪:用于跟踪用户的整个会话过程,常用的会话跟踪技术有Cookie、Session 。

因为在RESTful的无状态原则,Web Server不会保存任何的会话状态。所以RESTful一般使用Cookie来解决会话状态的保存。

Cookie

Web应用使用的HTTP是一种无状态协议,这意味着Web Server将对页面的每个HTTP请求当作独立的请求进行处理;服务器不保留与先前请求所使用的任何变量值有关的信息。使得Client和Server一旦完成了数据交换,他们之间的连接就会关闭,再次交换数据时,需要先建立新的连接。这造成了Client与Server无法从连接上跟踪会话。这就需要引用一种机制,来将无状态的HTTP连接,建立起联系(跟踪),避免会话间的混淆。

所以在Web应用中会话跟踪是必不可少的,会话跟踪能够保证每一个会话的独立性(一个用户的所有请求操作都属于同一个会话)。而Cookie能够弥补HTTP无状态传输的不足,在Client中创建一个文本文件来用于存贮Client浏览器与Web Server之间的联系。

Cookie原理:为每一个Client浏览器颁发一个通行证(ID Card),当Client浏览器向Web Server发送请求时候都必须带上自己的通行证,这样Web Server就能够通过请求中的通行证来确定Client的身份。

Cookie的实现:Client浏览器向Web Server发出请求,如果Web Server需要记录该Client用户的状态时,就会使用response向Client颁发一个Cookie,Client浏览器会将Cookie文件保存起来。这样当Client浏览器再次向Web Server发出请求时,就会将Cookie包含在请求中一同发送给Web Server。Web Server就能够通过请求中的Cookie来辨认用户状态,即识别Client的身份。

资源的表现形式

超链接:超链接在本质上属于一个网页的一部分,它是一种允许我们与其他网页或站点之间进行连接的元素。所谓的超链接是指从一个网页指向一个目标的连接关系,这个目标可以是另一个网页,也可以是相同网页上的不同位置,还可以是一个图片,一个电子邮件地址,一个文件,甚至是一个应用程序。

超文本:超文本是用超链接的方法,将各种不同空间的文字信息组织在一起的网状文本。超文本更是一种用户介面范式,用来显示文本及与文本之间相关的内容。现在超文本普遍以电子文档方式存在,其中的文字包含有可以链结到其他位置或者文档的连结,允许从当前阅读位置直接切换到超文本连结所指向的位置。我们日常浏览的网页上的链结都属于超文本。

超媒体:超媒体是一种采用非线性网状结构对块状多媒体信息(文本、图像、视频等)进行组织和管理的技术。超媒体在本质上和超文本是一样的,只不过超文本技术在诞生的初期管理的对象是纯文本,所以叫做超文本。随着多媒体技术的兴起和发展,超文本技术的管理对象从纯文本扩展到多媒体,为强调管理对象的变化,就产生了超媒体这个词。在RESTful之中超媒体作为资源的表现形式。

HATEOAS

Roy Thomas Fielding博士将REST定位为Distributed Hypermedia System(分布式超媒体应用)并在《Architectural Styles and the Design of Network-based Software Architectures》中提出了HATEOAS(Hypermedia as the engine of application state 超媒体作为应用状态的引擎)的概念。

应用状态:指的是Web Client的状态,可以理解为会话状态。

在Web Server中被Resource Request Handler确定的概念性实体(资源),以超媒体(Hypermedia)的形式展现在Client浏览器。当我们在Client中点击超媒体的链接(URI)时,就可以获取被链接(URI)关联的资源或者可以对资源进行特定的操作。获取的资源或者经特定操作响应后的资源在经过同样Resource Request Handler确定表现的形式(XML/JSON格式等)后,以超媒体的形式在表现在Client的浏览器中。而这种资源内容或形式的改变都会导致Client会话状态的改变,所以说超媒体成为了驱动Client会话状态转换的引擎(应用状态的改变基于超媒体的改变)

RESTful

因为超媒体作为资源在Client中的表现形式,所以Client应用状态的转换体现为Client浏览器中呈现资源的转换。而且资源对应的超媒体表现格式是由Web Server中的表现层决定的,如果将超媒体进一步抽象成一般意义上的资源呈现(Representation )方式,那么Client应用状态变成了可被呈现的状态(REpresentational State)。Client应用状态之间的转换就成了可被呈现的状态装换(REpresentational State Transfer),这就是REST。 —— 摘自博文《我所理解的RESTful Web API [设计篇]》

资源

资源寄存于Web Server,可以是一个具体的事物,如:文件、音乐、视频这也再次说明了超媒体是资源的表现形式。当然资源也可以指一个抽象的流程。

URI

是资源的唯一标识。URI具有标志性、可读性、可寻址性。

标志性:可以标识某个独立的资源,也可以标志一组资源的集合式资源容器(复杂型资源)。

可读性:RESTful的URI用于标识资源,所以URI中应该尽量使用名词来描述一个资源的类型,避免使用动词。

可寻址性:URI包含了URL的特性,可以定位寻址到某一个具体的资源位置。

上一篇:MySQL使用 IN 查询取出数据排序问题(与in排序相同、不排序)


下一篇:不同角度看Handler——另类三问