论坛首页 Web前端技术论坛

给Ajax技术初学者的一些建议

浏览 65468 次
该帖已经被评为精华帖
作者 正文
   发表时间:2007-05-15  
>> PUT /columns/1/subcolumns/1

我可不可以理解成REST是URI表面的尽量简化(实际上面的URL中包含了两个服务端所需要的查找资源的参数,column =1 && subcolumn=1),但是在提交到服务端时,在header中可以随意准备服务端所需要的一切参数?
0 请登录后投票
   发表时间:2007-05-15  
如果要删除一个对象集合的话,用REST方式,uri怎么写?
0 请登录后投票
   发表时间:2007-05-15  
jindw 写道
感觉这个帖子应该封贴了。

这个问题或许有点仁者见仁,智着见智的味道。
都在兴头上,思想更容易走向极端。

既然都没有办法短时间说服对方,不如让时间去证明一切。


要是能打出点创意就好了。 可惜buaawhl不在了
0 请登录后投票
   发表时间: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也可以。核心就是“资源”和针对“资源”施加的“操作”。

0 请登录后投票
   发表时间:2007-05-15  
hexiaodong 写道
如果要删除一个对象集合的话,用REST方式,uri怎么写?


DELETE  /orders


0 请登录后投票
   发表时间:2007-05-15  
sorphi 写道
>> PUT /columns/1/subcolumns/1

我可不可以理解成REST是URI表面的尽量简化(实际上面的URL中包含了两个服务端所需要的查找资源的参数,column =1 && subcolumn=1),但是在提交到服务端时,在header中可以随意准备服务端所需要的一切参数?


用header或body放参数当然可以 但是如果目的仅仅是要显示某条信息(单一资源) 这样做就不好了 即便google上有你的url别人也打不开。

因为他们不知道head或body中需要什么参数。缺少参数服务器不返回结果
0 请登录后投票
   发表时间: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出去。
0 请登录后投票
   发表时间: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协议去提交,也是误用。
0 请登录后投票
   发表时间: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对其进行简化。
0 请登录后投票
   发表时间: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一点都没关系。
0 请登录后投票
论坛首页 Web前端技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics