锁定老帖子 主题:关于REST的一点想法,欢迎大家讨论。
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2007-04-12
dennis_zane 写道 yuxie 写道 gigix 写道 登录/注销:如果把“会话”看作资源,这两个操作就是“会话”资源的create和delete 大可以把这些代码抽象出来,以后根本不用generate就能使。可是rails目前没有这么做。 咳: 所以,写着写着,新的结论出来了 能用ActiviRecord表示的东东使用REST很有前途 不能用ActiviRecord表示的东东使用REST很没前途 你把资源狭义化了,资源 !=ActiveRecord REST的资源更多的要求的是从资源去观察web操作,而并不是非要操纵ActiviRecord。REST是一种架构,更是一种思考方式 我没有说ActiveRecord就是资源。我是说ActiveRecord可以让REST的代码大大简化。而对非ActiveRecord的资源,用不用REST代码量都差不多,可读性还变差,所以没有必要。 |
|
返回顶楼 | |
发表时间:2007-04-12
凤舞凰扬 写道 对楼主的帖子有个小小疑问,也是自己没搞懂的。既然REST是Representation State Transfer,楼主又说所有操作都是无状态的,那么当中的State又是什么呢?
Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use. 从文字中理解, 每个选择的link都是一个state的改变。而点击link对于web系统来说,就是一种操作。看上去和楼主的无状态是矛盾的。 大家有何想法? REST提倡的stateless是指server是无状态的,也就是会所server不会保存与状态相关的信息(这当然是理想情况)。上面英文的大概意思是把网络应用看成一个有限状态机,那么对link的每次点击都会导致状态的跃迁,也就是state transition。Fielding的论文用的都是比较学术的词,看起来是比较麻烦。 Martin Flower的PEAA里面对状态这个东西(也就是session)的设计讲得很清楚。极少有网络应用不需要使用session,而HTTP是无状态的,所以问题就来了:在哪里保持session?Martin给出了三种方式:在client端、在server端和在database里。每种都有各自的优缺点。REST所谓的stateless,是说把session保持在client端,这样server就是stateless的。但是根据PEAA,这种做法也有trade-off,所以到底要怎么样,要看实际情况自己权衡。 |
|
返回顶楼 | |
发表时间:2007-04-12
yuxie 写道 能用ActiviRecord表示的东东使用REST很有前途 不能用ActiviRecord表示的东东使用REST很没前途 说白了是对于能够很直观地抽象为资源的东西REST比较合适。 yuxie 写道 我没有说ActiveRecord就是资源。我是说ActiveRecord可以让REST的代码大大简化。而对非ActiveRecord的资源,用不用REST代码量都差不多,可读性还变差,所以没有必要。 ActiveRecord本身就极大地简化了代码,无论你是用MVC、REST,甚至其它比较老的架构。 |
|
返回顶楼 | |
发表时间:2007-04-12
大家能不能讨论以下rest的安全性问题。
|
|
返回顶楼 | |
发表时间:2007-04-12
AllenYoung 写道 yuxie 写道 能用ActiviRecord表示的东东使用REST很有前途 不能用ActiviRecord表示的东东使用REST很没前途 说白了是对于能够很直观地抽象为资源的东西REST比较合适。 yuxie 写道 我没有说ActiveRecord就是资源。我是说ActiveRecord可以让REST的代码大大简化。而对非ActiveRecord的资源,用不用REST代码量都差不多,可读性还变差,所以没有必要。 ActiveRecord本身就极大地简化了代码,无论你是用MVC、REST,甚至其它比较老的架构。 我不是这个意思。 关于REST在rails中的使用,大家一定看过dongbin同学的帖子 http://www.iteye.com/topic/38856 在这里,大家能很容易就能看出REST根本不省代码: 没有REST:16行 用了REST:21行 但是,如果我们能把这一块代码抽象出来,放到改进后的ActiveRevord基类中去, 代码就能减少很多: class User < ActiveRecord::Base has_many :articles, :through => :unreadeds end class Article < ActiveRecord::Base has_many :users,:through => :unreadeds end class Unreaded < NewActiveRecord::Base end class UnreadedsController < ApplicationController scaffold_resource :product end 结果就是: 没有REST:16行 用了REST:12行 但是呢,目前只有ActiveRecord适合这个抽象,像session对象这种东东,统统干不了这个活 |
|
返回顶楼 | |
发表时间:2007-04-13
就我的理解来看,REST是否只是适合于WEB开发,对应以前传统的C/S或者WebService接口是否有参考价值呢?
在我看来,开发的趋势应该是更容易抽象理解,更符合一般人的思维方式才好 |
|
返回顶楼 | |
发表时间:2007-04-13
yuxie 写道 robbin以前说过REST能让代码减少到很少的程度(具体到多少忘了)。现在看来似乎有点言过其实。REST远没有想像中的那么强大。在我看来,如果采用纯REST架构的话,所谓的resource就是经过阉割的OO模型,只有属性,没有行为。为了表现这些被切掉的行为,我必须凭空再造出一个个所谓的resource来,切掉的行为越多,要造的就越多。这样的话,代码不可能有数量级的减少。再想一下,仅仅为了漂亮的URL,放弃自然和符合人类思维习惯的OO模型,这样真的值吗。套用T1同学的话来说:辛辛苦苦几十年,一夜回到了解放前。
所以我认为,REST只是在异构系统之间的webservice通讯上有优势,其他时候,还是该匝地匝地比较好。 我觉得Web应用很多地方都不适合OO,前台请求-》服务器处理-》返回结果不就是完全的面向过程的程序么? REST拟或Rails开发真正有让我们眼前一亮的感觉。 套用搜狗的一句广告词:“REST更懂网络” |
|
返回顶楼 | |
发表时间:2007-04-13
weiqingfei 写道 大家能不能讨论以下rest的安全性问题。
如果rest想用ajax直接来调用web service安全性肯定有问题. ws不是单一的服务器端调用 往往需要将一个ws的输出加工发向第2个ws进行处理, 如此如此. 将所有ws需要的密码都传到客户端是可怕的. 在性能上ajax也会出问题 js用到现在已经超复合了 越来越难维护. rest只是一种理论 完全按理论来肯定不行. 我想有一个办法能解决所有的问题 那就是添加一个中间层次 ajax->ws 变为 ajax->中间层->ws 中间层将数据加工认证后发给ws 同时为ajax提供view减轻ajax端的负担. |
|
返回顶楼 | |
发表时间:2007-04-13
REST是不是和以前Zope对资源处理的方式比较类似?如果是这样,那Zope处理资源的方式是不是更加成熟一些呢?
|
|
返回顶楼 | |
发表时间:2007-04-13
winterwolf 写道 weiqingfei 写道 大家能不能讨论以下rest的安全性问题。
如果rest想用ajax直接来调用web service安全性肯定有问题. ws不是单一的服务器端调用 往往需要将一个ws的输出加工发向第2个ws进行处理, 如此如此. 将所有ws需要的密码都传到客户端是可怕的. 在性能上ajax也会出问题 js用到现在已经超复合了 越来越难维护. rest只是一种理论 完全按理论来肯定不行. 我想有一个办法能解决所有的问题 那就是添加一个中间层次 ajax->ws 变为 ajax->中间层->ws 中间层将数据加工认证后发给ws 同时为ajax提供view减轻ajax端的负担. 就REST本身来讲,脱离了ajax,就没有了什么意义,因为浏览器本身是不支持put delete的, 如果只谈它的理论的话,我想这个早就在做了,比如url的重定向,可以实现面向资源的操作。 ajax不可能一直保留着用户名密码传来传去,应该还是用cookie的方式保持sessionid,但是这样又违背了”服务器无状态“这句话。 我想安全性问题还是在应用REST时比较头痛的问题。 |
|
返回顶楼 | |