锁定老帖子 主题:给Ajax技术初学者的一些建议
该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2007-05-15
>> PUT /columns/1/subcolumns/1
我可不可以理解成REST是URI表面的尽量简化(实际上面的URL中包含了两个服务端所需要的查找资源的参数,column =1 && subcolumn=1),但是在提交到服务端时,在header中可以随意准备服务端所需要的一切参数? |
|
返回顶楼 | |
发表时间:2007-05-15
如果要删除一个对象集合的话,用REST方式,uri怎么写?
|
|
返回顶楼 | |
发表时间:2007-05-15
jindw 写道 感觉这个帖子应该封贴了。
这个问题或许有点仁者见仁,智着见智的味道。 都在兴头上,思想更容易走向极端。 既然都没有办法短时间说服对方,不如让时间去证明一切。 要是能打出点创意就好了。 可惜buaawhl不在了 |
|
返回顶楼 | |
发表时间:2007-05-15
sorphi 写道 >> PUT /columns/1/subcolumns/1
我可不可以理解成REST是URI表面的尽量简化(实际上面的URL中包含了两个服务端所需要的查找资源的参数,column =1 && subcolumn=1),但是在提交到服务端时,在header中可以随意准备服务端所需要的一切参数? 理解的不对。REST的含义包含了好几个方面,我前面已经提到了,这里不复述了。 URI是资源,要把资源用URI唯一性表达出来,参数的传递不一定非要通过POST的body传递(注意,参数可不是通过header传递的,又是一个对HTTP协议没有入门的家伙),GET的querystring也可以。核心就是“资源”和针对“资源”施加的“操作”。 |
|
返回顶楼 | |
发表时间:2007-05-15
hexiaodong 写道 如果要删除一个对象集合的话,用REST方式,uri怎么写?
DELETE /orders |
|
返回顶楼 | |
发表时间:2007-05-15
sorphi 写道 >> PUT /columns/1/subcolumns/1
我可不可以理解成REST是URI表面的尽量简化(实际上面的URL中包含了两个服务端所需要的查找资源的参数,column =1 && subcolumn=1),但是在提交到服务端时,在header中可以随意准备服务端所需要的一切参数? 用header或body放参数当然可以 但是如果目的仅仅是要显示某条信息(单一资源) 这样做就不好了 即便google上有你的url别人也打不开。 因为他们不知道head或body中需要什么参数。缺少参数服务器不返回结果 |
|
返回顶楼 | |
发表时间:2007-05-15
winterwolf 写道 我是不大敢和坛主交锋的
robbin肯定是有一些实践体会的 dlee也是所以很自信。其实他们谈的我不仅明白还做过。 但是那 直接用post一样能实现rest 而且不仅仅局限于rest 我想这个dlee没有尝试过 否则不会一再误会我的意思。 我只所以觉得post更出色 是因为有些应用根本就不是面向资源的 只是要返回加工后的结果 当然用rest的方式也不是不可以 但是很别扭。 谈到这里就不得不说说SOA 。也就是组合web servic的问题。 有时候信息服务并非是对某个资源的访问。 比如我现在要获得所有连锁俱乐部的服务价格清单 并用execel输出 然后email给apple. 在ajax中这是一步操作 只需返回ok 如果用rest去实现它 。。。。 这个留给rest狂热分子去思考吧虽然我也有办法 因为HTML不支持PUT/DELETE,所以RoR实际上就是用POST去模拟的PUT和DELETE。如果用纯AJAX,就没有这方面的限制。 你说的应用场景,获取服务价格清单就是对资源的访问,以excel的格式输出这也毫无疑问是REST。实际上REST的R就是这个意思,针对一项资源具有多种表象,excel格式也是一种表象。将资源的excel表象email出去,这个是和其他系统的交互(和Email Server的交互),不是REST范畴要解决的问题。当然就具体实践来说,你当然可以直接的get方法里面email出去。 |
|
返回顶楼 | |
发表时间:2007-05-15
winterwolf 写道 sorphi 写道 >> PUT /columns/1/subcolumns/1
我可不可以理解成REST是URI表面的尽量简化(实际上面的URL中包含了两个服务端所需要的查找资源的参数,column =1 && subcolumn=1),但是在提交到服务端时,在header中可以随意准备服务端所需要的一切参数? 用header或body放参数当然可以 但是如果目的仅仅是要显示某条信息(单一资源) 这样做就不好了 即便google上有你的url别人也打不开。 因为他们不知道head或body中需要什么参数。缺少参数服务器不返回结果 这你就错了,搜索引擎只会去访问超文本连接,他不会尝试去触发页面的form提交。这也算是很多人对HTTP协议基础知识缺失。 GET代表对互联网资源的访问,但不改变资源的状态,对于同一个URL,无论重复发送多少次GET请求,都应该返回同样的数据。所以很多人在web项目编程中很不注意这一点,删除或者修改的link也用GET,这全部都是误用,也有某种程度的安全隐患。 POST/PUT/DELETE代表修改互联网资源的状态,参数一般不通过URL的querystring传递,而是通过请求的body。 所以搜索引擎只会去爬超文本连接,不会去触发页面POST。如果目的是显示信息,那么通过POST协议去提交,也是误用。 |
|
返回顶楼 | |
发表时间:2007-05-15
robbin 写道 因为HTML不支持PUT/DELETE,所以RoR实际上就是用POST去模拟的PUT和DELETE。如果用纯AJAX,就没有这方面的限制。 你说的应用场景,获取服务价格清单就是对资源的访问,以excel的格式输出这也毫无疑问是REST。实际上REST的R就是这个意思,针对一项资源具有多种表象,excel格式也是一种表象。将资源的excel表象email出去,这个是和其他系统的交互(和Email Server的交互),不是REST范畴要解决的问题。当然就具体实践来说,你当然可以直接的get方法里面email出去。 是啊超出rest的范围了。 但商务系统中ajax发出多就是这样的指令性信息 将其以excel输出有时也不是简单的事情 可能也超出rest的范围了 比如excel模板是由另外一个web service提供的 而非在rest内部 rest的范围没有传统ws定义的范围广泛。 我认为信息类应该使用rest简单而且便于搜索。商务系统应该借鉴传统ws的定义采用post对其进行简化。 |
|
返回顶楼 | |
发表时间:2007-05-15
robbin 写道 引用 上面我说了对于复杂资源,有N多的操作,其中大部分操作只能共用一个PUT操作,这时REST唯一的稻草就是在请求中加一个Action参数来表示到底要干什么。这绝对不是REST的优美之处,yes?
嗯,我明白了你的意思。但是你这个担心很可能是多余的。例如 PUT /columns/1/subcolumns/1 定义了对某子栏目的修改操作,但是修改可能包括了:修改子栏目名称,发布子栏目,撤除子栏目。 按照你的理解,需要通过传递参数来标示不同的操作类型,例如: _action=modify _action=publish _action=remove 这是典型的Java Struts编程思维,我记得在n年前,我为了合并同类型操作,就需要在页面里面放入隐藏域标示操作类型,以便在action代码里面根据类型做相应操作。 但是RoR很可能不需要: 如果是修改子栏目,那么页面表单提交会包含 [subcolumn][name]="xxx" 这样的信息 如果是发布子栏目,那么页面表单提交会包含 [subcolumn][publish]="true" 这样的信息 如果是修改子栏目,那么页面表单提交会包含 [subcolumn][publish]="false" 这样的信息 最终PUT对应的都是同一个方法: def update subcolumn = SubColumn.find_by .... subcolumn.update_attributes(params[:subcolumn]) end 不管你是干嘛的,我就是这么一条语句搞定,根本不需要什么action参数。 通过POST/PUT的body携带的参数,已经可以很清楚的表明,要做的是什么事情了。实践上不需要什么action参数。当然很复杂的情况,也许需要增加点额外的判断。但是总体来说,需要增加的额外判断不多,也不会很复杂。 这才是大版主讨论问题的态度嘛, 。语气平和,说事实讲道理,以理人服人,不以势压人,世间没有绝对真理,谁都有看走眼的时候,对错有什么关系呢,地球还不照样转----扯远了。 版主大人还是没有完全明白我的意思: 你再想想,在复杂资源中,PUT要处理的各种操作并非只是更改资源属性这么简单,比如上面我的例子: 1、修改子栏目put:除了涉及修改栏目属性,还要保存栏目相关附件文件,设置修改日志等等,这些工作其他put是不需要的; 2、发布子栏目put:除了涉及修改栏目属性,还要更新栏目内容缓存,更新栏目全文检索的索引等等,这些工作其他put是不需要的; 3、移动子栏目put:除了涉及修改栏目属性,还要检查目标父栏目是否允许移入等等,这些工作其他put是不需要的; 。。。。。。。 也就是说很多操作其实都不是简单的原子操作,而是复杂的事务操作,这是我一直强调的。 如果要在一个PUT的处理代码中完成所有这些操作,只能引入一个巨大的swith case来处理,而case的条件参数,你不叫action,也得叫command,不叫command,也得叫do。。。反正英语表达行为就那么几个词,你是逃不掉的,和struct一点都没关系。 |
|
返回顶楼 | |