对REST中无状态(stateless)的理解

无状态指的是任意一个Web请求必须完全与其他请求隔离，当请求端提出请求时，请求本身包含了相应端为相应这一请求所需的全部信息。

 

那么对于用户来说，怎么感觉的有状态与无状态的差别呢。简单的方法是浏览器的后退按钮，如果一个网站期望用户以A->B->C的流程来交互，而在执行至B时回退的话，那么系统很有可能不是按照其所期望的方式运行，因为用户的状态可能被不可逆地修改了。反过来，搜索引擎（我指的是普通意义上的搜索引擎，而不是根据用户搜索历史个性化了的）是一个无状态架构的范例。任何用户可以在浏览器地址栏中输入http://www.google.com/search?q=RESTful&start=100来获得从第一百条开始的关于RESTful的记录，并且当Google摩洛哥服务器瘫痪时，相关用户请求会被透明地移送至其他服务器。

 

RESTful架构对于state的两个不同的解释: 应用状态(Application State)和资源状态(Resource State)。应用状态指的是与某一特定请求相关的状态信息，而资源状态则反映了某一存储在服务器端资源在某一时刻的特定状态，该状态不会因为用户请求而改变，任何用户在同一时刻对该资源的请求都会获得这一状态的表现（Representation）。RESTful架构要求服务器端不保有任何与特定HTTP请求相关的资源，所以应用状态必须由请求方在请求过程中提供。那么再回到那个邮件列表中的问题，为什么传递一个session ID是违背REST架构风格而传递user credentials却不是。我想作者的疑惑源于他没有分清什么是有状态和无状态的架构属性，而认为“传递某种表示状态的信息”到服务器便是“有状态”的表现。其实有状态和无状态与请求本身没有多大关联，重要的是状态信息是由请求方还是响应方负责保存。在Session ID可以被认为是一个用来标识某一会话状态的Key，将其传递给服务器端意味着这样一个请求：“请帮我取出这个状态信息”，也就是说这个请求假设响应方保有着状态信息。由于与某一特定请求相关的状态属于应用状态，而RESTful架构要求任何此类状态由请求方负责提供，所以传递Session ID被认为是unRESTful的做法。反过来，user credential作为一种应用状态，是被期望由请求方提供的，所以在请求中传递user credentials（姑且忽略安全性问题）是符合RESTful架构规范的。