原文链接:http://www.cnblogs.com/Nyyrikki/archive/2009/06/16/1504191.html
今天早上在Yahoo的邮件列表里看到一篇颇有意思的讨论,标题为RESTful vs. unRESTful: Session IDs and Authentication(http://tech.groups.yahoo.com/group/rest-discuss/message/12870
)。
文中让发起讨论的朋友大惑不解的是这样一个问题:为什么在请求中传递SessionID被普遍认为是unRESTful的,而将用户的
credentials包含在每个请求里又是一种非常RESTful的做法。看了他接下来对于REST架构风格中"statelessness"属性的理
解后,我觉得有必要对这个经常会被人误解词汇以及相关概念做一个简要的整理,希望能够通过这篇随笔解释清楚什么是状态,为什么要实现无状态,以及REST
风格架构中的两种状态的区别,最后我会从我的理解出发来回答作者提出的这个问题。
首先,一个Web应用程序协议的“状态”在通常指的是为两个相互关联的用户交互操作保留的某种公共信息,它们常常被用来存储工作流或用户状态信息等
数据。这些信息可以被指定不同的作用域如page,request,session或全局作用域,而存储他们的责任也同样可以由Client端或
Server端负责。虽然存储状态为企业软件开发带来了诸多便利,但是它也给分布式系统的其他方面带来了许多限制,比如在负载均衡方面,在有状态的模式
下,一个用户的请求必须被提交到保存有其相关状态信息的服务器上,否则这些请求可能无法被理解,这也就意味着在此模式下服务器端无法对用户请求进行自由调
度。于此相关的另一个问题是容错性,倘若保有用户信息的服务器宕机,那么该用户最近的所有交互操作将无法被透明地移送至备用服务器上,除非该服务器时刻与
主服务器同步全部用户的状态信息。此外,由于HTTP本身不是一个有状态的协议,开发人员必须通过模拟实现状态的钝化与激活等。于是为了克服这些不足,无
状态(Statelessness)架构风格属性受到了广泛关注。
无状态指的是任意一个Web请求必须完全与其他请求隔离,当请求端提出请求时,请求本身包含了相应端为相应这一请求所需的全部信息。这一约束的出现
改善了分布式系统的可见性、可靠性以及可伸缩性,具体的介绍可以参考Roy T.
Fielding博士的论文,这里就不哆嗦了。这些从整个系统角度来看无状态似乎过于抽象,那么对于用户来说,怎么感觉的有状态与无状态的差别呢。简单的
方法是浏览器的后退按钮,如果一个网站期望用户以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架构规范的。
这篇随笔或多或少散发着某种纯粹主义的味道,但我觉得有些概念是值得玩味的。任何一种架构风格的出现都有其期望的,对现有方案的改进或期望克服的问
题。作为REST来说,它所期望的是组件的可伸缩性,组件的独立部署,接口统一等特性,而无状态作为实现这组需求的一个特性,个人认为是有必要清楚了解并
在实际开发过程中落实的。
分享到:
相关推荐
联盟的无国籍状态 演示文稿,关于所有新旧事物。 此演示文稿旨在以白底绿配色方案中的主题“Plain Jane”观看
11. Ajax Applications as REST Clients.... . . . . . . 315 From AJAX to Ajax 315 The Ajax Architecture 316 A del.icio.us Example 317 The Advantages of Ajax 320 The Disadvantages of Ajax 320 REST ...
function waiting for the rest of its parameters. It’s also common for functional languages to offer type systems with much better power-to-weight ratios, providing more performance and correctness ...
基于springboot的java毕业&课程设计
基于springboot的java毕业&课程设计
基于springboot的java毕业&课程设计
基于卷积神经网络的语义分割卷积神经网络(Convolutional Neural Networks, CNNs 或 ConvNets)是一类深度神经网络,特别擅长处理图像相关的机器学习和深度学习任务。它们的名称来源于网络中使用了一种叫做卷积的数学运算。以下是卷积神经网络的一些关键组件和特性: 卷积层(Convolutional Layer): 卷积层是CNN的核心组件。它们通过一组可学习的滤波器(或称为卷积核、卷积器)在输入图像(或上一层的输出特征图)上滑动来工作。 滤波器和图像之间的卷积操作生成输出特征图,该特征图反映了滤波器所捕捉的局部图像特性(如边缘、角点等)。 通过使用多个滤波器,卷积层可以提取输入图像中的多种特征。 激活函数(Activation Function): 在卷积操作之后,通常会应用一个激活函数(如ReLU、Sigmoid或tanh)来增加网络的非线性。 池化层(Pooling Layer): 池化层通常位于卷积层之后,用于降低特征图的维度(空间尺寸),减少计算量和参数数量,同时保持特征的空间层次结构。 常见的池化操作包括最大池化(Max Pooling)和平均
track-map_android-master
dAFASFDSGSFDGFDHDFG
毕设设计-学生宿舍管理系统 基于SpringBoot实现,界面简洁,功能完善 主要功能 ● 定位打卡、宿舍智能分配、学生信息管理、资讯管理(权限设计)等 使用 ● mysql、git、springboot ● 数据库初始化sql存储在doc文件夹下面 设计一个基于Spring Boot的学生宿舍管理系统,你需要确保系统既满足实用性,又保证界面简洁、功能完善。以下是一个基本的设计方案,包括系统的功能模块、技术栈选择和界面设计要点。 ### 功能模块 1. **用户认证模块**: - 登录/登出功能。 - 用户权限管理(如学生、宿舍管理员、系统管理员)。 2. **学生信息管理**: - 学生基本信息录入、查询、修改和删除。 - 宿舍分配与调换。 3. **宿舍楼管理**: - 宿舍楼信息维护。 - 宿舍房间信息管理。 4. **维修报修管理**: - 学生报修申请。 - 维修状态跟踪。 5. **来访登记管理**: - 来访人员登记。 - 访问记录查询。 6. **公告与通知发布**: - 发布宿舍相关公告和通知。
课设毕设基于SSM的宝康药房销售管理系统 LW+PPT+源码可运行.zip
python网络爬虫-入门基础学习爬虫原理.zip
PictureSelectDemo-master
基于 YOLOv5 的实时摄像机馈送中识别对象-主体
基于springboot的java毕业&课程设计
该数据集大小为300张120×120地白细胞图片
结构型设计模式(7种)
基于springboot的java毕业&课程设计
MySQL8.4.0 LTS(mysql-test-8.4.0-linux-glibc2.17-aarch64.tar.xz)适用于Linux Generic aarch64 glibc2.17
GaodeMapDemo-master