|
精华帖 (11) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-07-07
dlee 写道 winterwolf 写道 dlee说过俺英文不及格滴 lordaeron也不及格吗
你这个同志就是喜欢对号入座，我没有说你啊。 Lordaeron的英语显然不及格，连上面我贴的那么浅显的英文都能读错，凭空诬陷好人（WebDAV）的清白，如果再继续大言不惭实在是有些过分了。 哦那就好 不能冤枉好人嘛 如果用webdav协议构建rest系统是不是比http更优秀那 ？ 比如灵活性 效率等等 而且不仅可以通过浏览器访问还可以通过windows和linux网络文件夹访问或编辑rss atom wiki. 后边还可以和svn集成起来 |
| 返回顶楼 | |
|
发表时间：2007-07-07
dlee前面关于“状态”的解释说到我心里去了。早就想说了，貌似有些人对状态的理解无限扩大化了
|
| 返回顶楼 | |
|
发表时间：2007-07-07
恩 将状态看作资源 就无状态了。
资源千秋万载一统。。 |
| 返回顶楼 | |
|
发表时间：2007-07-08
winterwolf 写道 恩 将状态看作资源 就无状态了。
对，一局牌其实是一个抽象的资源，这个资源的状态，客户端可以获取、操作和修改，但是状态始终是保存在服务器端的。 上面我说的一个工作流，其实也是一个抽象的资源，它的状态也是保存在服务器端的。每个用户执行的一步操作，不能看作是从属于这个用户自身的状态，而是改变了这个工作流资源的状态。 这些场景都与REST并不冲突。 REST的无状态服务器的架构约束，直接继承自客户-无状态-服务器（Client-Stateless-Server，CSS）架构风格。 Fielding 写道 3.4.3 客户-无状态-服务器（Client-Stateless-Server，CSS）
客户-无状态-服务器风格源自客户-服务器风格，并且添加了额外的约束：在服务器组件之上不允许有会话状态（session state）。从客户端发到服务器的每个请求必须包含理解请求所必需的全部信息，不能利用任何保存在服务器上的上下文（context），会话状态全部保存在客户端。 这些约束改善了可见性、可靠性和可伸缩性3个架构属性。可见性的改善是因为监视系统再也不必为了确定请求的全部性质而查看多个请求的数据。可靠性的改善是因为这些约束简化了从部分故障中恢复的任务[133]。可伸缩性的改善是因为不必保存多个请求之间的状态，允许服务器组件迅速释放资源并进一步简化其实现。 客户-无状态-服务器风格的缺点是：因为我们不能将状态数据保存在服务器上的共享上下文中，通过增加在一系列请求中发送的重复数据（每次交互的开销），可能会降低网络性能。 注意看，这里明确说的是会话状态，而不是其他类型的状态。 Fielding 写道 5.1.3 无状态
我们接下来再为客户-服务器交互添加一个约束：通信必须在本质上是无状态的，如3.4.3小节中的客户-无状态-服务器（CSS）风格那样，因此从客户到服务器的每个请求都必须包含理解该请求所必需的所有信息，不能利用任何存储在服务器上的上下文，会话状态因此要全部保存在客户端。 这个约束导致了可见性、可靠性和可伸缩性三个架构属性。改善了可见性是因为监视系统不必为了确定一个请求的全部性质而去查看该请求之外的多个请求。改善了可靠性是因为它减轻了从局部故障[133]中恢复的任务量。改善了可伸缩性是因为不必在多个请求之间保存状态，从而允许服务器组件迅速释放资源，并进一步简化其实现，因为服务器不必跨多个请求管理资源的使用。 与大多数架构上抉择一样，无状态这一约束反映出设计上的权衡。其缺点是：由于不能将状态数据保存在服务器上的共享上下文中，因此增加了在一系列请求中发送的重复数据（每次交互的开销），可能会降低网络性能。此外，将应用状态放在客户端还降低了服务器对于一致的应用行为的控制，因为这样一来，应用就得依赖于跨多个客户端版本（译者注：例如多个浏览器窗口）的语义的正确实现。 一个忠告：在声称自己完全理解了Fielding的含义，甚至比Fielding更懂HTTP之前，最好还是慎重一些。 |
| 返回顶楼 | |
|
发表时间：2007-07-08
张三打的牌跟张三这个会话是有关的，肯定也是保存在张三这局牌的会话中的，所以它当然是会话状态。如果你说这局牌是一个资源，这个状态是资源本身的状态，而跟张三无关的话，那么请问，如果你不以 Session 形式保存这个你说的资源的状态，那么你打算把这个资源的状态怎么样保存在服务器上？以 Appliction 的级别保存吗？如果以 Application 形式保存，难道不是更影响系统的可伸缩性吗？
|
| 返回顶楼 | |
