2006-12-27
rails作者DHH谈及REST
关键字: REST
http://www.loudthinking.com/arc/000602.html
CSDN上面有中文的翻译:
http://blog.csdn.net/dhansson/archive/2006/11/26/1415180.aspx
标题是“死星不可避免的灭亡 ”,引用星球大战的典故,含义是说对于那些庞大商业公司和机构搞出来的貌似威力无比的SOAP和Web Services就好像星球大战中帝国军队建造的终极武器-死星。
现在感觉起来我们已经到了星球大战-新希望这部电影的最后20分钟。......
而对甲板上的帝国指挥官来说,我敢肯定他们没有什么需要担心的事情标准化过程正在全速前进。我们有委员会来监督委员会。所以,一小拨叛逆的黑客的咕嘟很难改变什么。难道他们不知道死星很快就要完全投入使用吗?
......我肯定EJB和CORBA的推动者同样认为他们是不可战胜的,......
可能这就是IT业内一个大的运作的方法。我们必须要有一个复杂性深不可测的新的前沿以迷失于中。这个前沿需要工具修整,庞大的顾问团队,5年的任务计划,和进出的障碍
DHH认为了SOAP就像帝国军队的死星那样,貌似强大,却终将陨落。而推翻SOAP统治,取代SOAP成为网络web服务的REST虽然看似不值得一提,却终将获胜。
另外最近Google废除了以前发表的Google SOAP API,改用AJAX来提供Search服务了。
很有意思的事情和趋势,让我们明年好好看看是否REST将掀起真正的web服务革命吧,这是SOAP搞了六年都没有搞成功的事情。
BTW:很可惜这么好的文章在CSDN却没有什么点击和回复,sign~
CSDN上面有中文的翻译:
http://blog.csdn.net/dhansson/archive/2006/11/26/1415180.aspx
标题是“死星不可避免的灭亡 ”,引用星球大战的典故,含义是说对于那些庞大商业公司和机构搞出来的貌似威力无比的SOAP和Web Services就好像星球大战中帝国军队建造的终极武器-死星。
引用
现在感觉起来我们已经到了星球大战-新希望这部电影的最后20分钟。......
而对甲板上的帝国指挥官来说,我敢肯定他们没有什么需要担心的事情标准化过程正在全速前进。我们有委员会来监督委员会。所以,一小拨叛逆的黑客的咕嘟很难改变什么。难道他们不知道死星很快就要完全投入使用吗?
......我肯定EJB和CORBA的推动者同样认为他们是不可战胜的,......
可能这就是IT业内一个大的运作的方法。我们必须要有一个复杂性深不可测的新的前沿以迷失于中。这个前沿需要工具修整,庞大的顾问团队,5年的任务计划,和进出的障碍
引用
即将到来的Rails 1.2令我兴奋的就是它全部是关于尽量的让REST成为网络程序员自然的解决方案。肯定有很多人在某个方面根本不在乎。他们就是那些处于危机的人。但是使REST成为标准根本不难。REST已经很简单了。混合一点帮助,指导,和集成的常规,很快,程序员对项目经理实现SOAP接口的要求的反应就会是:”你真的想让我这么做?!?!”
DHH认为了SOAP就像帝国军队的死星那样,貌似强大,却终将陨落。而推翻SOAP统治,取代SOAP成为网络web服务的REST虽然看似不值得一提,却终将获胜。
另外最近Google废除了以前发表的Google SOAP API,改用AJAX来提供Search服务了。
很有意思的事情和趋势,让我们明年好好看看是否REST将掀起真正的web服务革命吧,这是SOAP搞了六年都没有搞成功的事情。
BTW:很可惜这么好的文章在CSDN却没有什么点击和回复,sign~
评论
seadog
2007-04-10
不错的
winterwolf
2007-04-05
weiqingfei 写道
winterwolf 写道
rest在读完head后一样还是要解析xml读数据啊 简单在那里?
怎么老扯到xml呢?
rest处理4类请求,再细的颗粒是还要自己做呀。
你可能误会了. 我明白rest的概念.
我是想将rest ws和soap ws放到soa中进行对比
至于soa为什么老扯到xml我就不回答了
winterwolf
2007-04-05
gigix 写道
winterwolf 写道
rest在读完head后一样还是要解析xml读数据啊 简单在那里?
普通的请求,哪里有xml什么事情?
假定传输的内容是xml文档.
weiqingfei
2007-04-05
winterwolf 写道
rest在读完head后一样还是要解析xml读数据啊 简单在那里?
怎么老扯到xml呢?
rest处理4类请求,再细的颗粒是还要自己做呀。
gigix
2007-04-05
winterwolf 写道
rest在读完head后一样还是要解析xml读数据啊 简单在那里?
普通的请求,哪里有xml什么事情?
winterwolf
2007-04-05
rest在读完head后一样还是要解析xml读数据啊 简单在那里?
将动作放到xml好处就多了
<acts>
<act url="sv1">
保存定单
<go>sv2</go>
<act>
<act url="sv2">
备份定单
<go>sv3</go>
<act>
<act url="sv3">
发货单
<go>end</go>
<act>
<acts>
将动作放到xml好处就多了
<acts>
<act url="sv1">
保存定单
<go>sv2</go>
<act>
<act url="sv2">
备份定单
<go>sv3</go>
<act>
<act url="sv3">
发货单
<go>end</go>
<act>
<acts>
weiqingfei
2007-04-05
winterwolf 写道
rest确实是放在head里 这个方法也许只对不擅长处理xml的开发框架简单
其实用xslt或者直接用xquery即可对xml中的动作进行判断.
多数人不熟悉cocoon ops这样的框架所以认为这么做复杂.
我觉得这个和xml应该扯不上什么关系。其实用xslt或者直接用xquery即可对xml中的动作进行判断.
多数人不熟悉cocoon ops这样的框架所以认为这么做复杂.
动作这个东西,可以放在任何地方,以任何形式表现。只要接收端能正确解析就可以。
rest只不过应用了http所支持东西来做,从形式上更加简练。
winterwolf
2007-04-05
rest确实是放在head里 这个方法也许只对不擅长处理xml的开发框架简单
其实用xslt或者直接用xquery即可对xml中的动作进行判断.
多数人不熟悉cocoon ops这样的框架所以认为这么做复杂.
其实用xslt或者直接用xquery即可对xml中的动作进行判断.
多数人不熟悉cocoon ops这样的框架所以认为这么做复杂.
weiqingfei
2007-04-05
winterwolf 写道
weiqingfei 写道
这儿的唯一性,不是绝对的唯一性,而是一种相对的唯一性。
对于操作,它只是抽象出经常用的4大类,分布在这4大类里的更细小的颗粒,还是要用url的方式(或者其它传统方式)来实现了。
由于head的局限性,不大可能把所有的服务都隐蔽在url之后。
至于这样的拆分,是更清晰了,还是更加混乱了,这就是仁者见仁,智者见智的事情了。
看来这只有借助具体实践来检验了
如果用url来指定ws的操作可以让xml中不包括具体的动作 order.com/order.save
<order>
<guessinfo/>
<goods/>
<参数>
<目标数据>/xmldb/order</目标数据>
......其它的比如 我们常用的?后面的paramater
</参数>
<order>
如果要用一个url来处理所有ws的操作那么就必需给xml加上动作指令 server端也必需做判断 order.com/order
<order>
<guessinfo/>
<goods/>
<参数/>
<动作>save</动作>
<order>
究竟哪个方式好 ?
对于WS是这个样子的。
但是对于rest,动作不是放在数据区的,而是放在了head里面。
get,post,put,delete是http很早就有的,但是为什么以前都是用get,post,很少关注put,delete呢?
因为现有浏览器很难支持。
现在开始关注rest,我想也是由于ajax所带动起来的,因为xmlhttprequest可以随意指定请求方式。
以前靠的是解析你的url来判断动作,现在只不过靠的请求方式来判断动作。
哪个方式好,我不敢妄言。
至于难以测试,客户端,ajax本来就难以测试,多加一个也无妨。
服务器端,我没有用过ror,不知道是怎么解析下发的,java的servlet对4中操作是支持的,内容形式的话估计还是要靠自己来判断,我想服务器端的测试,应该没有增加难度。
winterwolf
2007-04-05
那个方式好仅仅从服务内部是看不出来的.
当ws互相调用的时候可能差别就很大.也许是多url方便也许是一个url方便
但是有一点可以肯定就是多URL便于测试.
当ws互相调用的时候可能差别就很大.也许是多url方便也许是一个url方便
但是有一点可以肯定就是多URL便于测试.
winterwolf
2007-04-05
weiqingfei 写道
这儿的唯一性,不是绝对的唯一性,而是一种相对的唯一性。
对于操作,它只是抽象出经常用的4大类,分布在这4大类里的更细小的颗粒,还是要用url的方式(或者其它传统方式)来实现了。
由于head的局限性,不大可能把所有的服务都隐蔽在url之后。
至于这样的拆分,是更清晰了,还是更加混乱了,这就是仁者见仁,智者见智的事情了。
看来这只有借助具体实践来检验了
如果用url来指定ws的操作可以让xml中不包括具体的动作 order.com/order.save
<order>
<guessinfo/>
<goods/>
<参数>
<目标数据>/xmldb/order</目标数据>
......其它的比如 我们常用的?后面的paramater
</参数>
<order>
如果要用一个url来处理所有ws的操作那么就必需给xml加上动作指令 server端也必需做判断 order.com/order
<order>
<guessinfo/>
<goods/>
<参数/>
<动作>save</动作>
<order>
究竟哪个方式好 ?
weiqingfei
2007-04-05
dongbin 写道
winterwolf 写道
weiqingfei 写道
rest提倡的一个观点就是uri的唯一性,对于同一内容的不同形式,以及不同动作都是通过同一个uri来完成的。把传统用uri来标识的动作,用html的head来标识。
这正是我不理解的地方. 比如order.com是一个定单服务 那么所有对定单的操作都要用一个URL! 仅仅对一个定单的操作可以仅仅用save delete update 但是如果对全部定单进行备份和查询怎么办 ?
很多服务都被荫藏在url之后 这样rest还是会变的越来越复杂 最后变成官方的ws.
一旦服务被荫蔽在url之后 其它人就很难了结服务的内容及如何调用服务. 为什么不用url来表示资源和操作用guessorder.save allorder.backup 这样不是更简单更现实吗?
我的理解,
一个普通的html请求是一棵树,
REST的请求是树枝,
WS是叶子。
当然,最终,要的都是叶子。
winterwolf
2007-04-05
dongbin 写道
REST is a kind of tech to implement Webservice.
是 但是很概念 具体如何做还不很清晰.唯一明确的就是对ajax类客户端的肯定.
服务端如何做没有官方WS那样明确的规划.还需要探讨
weiqingfei
2007-04-05
winterwolf 写道
weiqingfei 写道
rest提倡的一个观点就是uri的唯一性,对于同一内容的不同形式,以及不同动作都是通过同一个uri来完成的。把传统用uri来标识的动作,用html的head来标识。
这正是我不理解的地方. 比如order.com是一个定单服务 那么所有对定单的操作都要用一个URL! 仅仅对一个定单的操作可以仅仅用save delete update 但是如果对全部定单进行备份和查询怎么办 ?
很多服务都被荫藏在url之后 这样rest还是会变的越来越复杂 最后变成官方的ws.
一旦服务被荫蔽在url之后 其它人就很难了结服务的内容及如何调用服务. 为什么不用url来表示资源和操作用guessorder.save allorder.backup 这样不是更简单更现实吗?
这儿的唯一性,不是绝对的唯一性,而是一种相对的唯一性。
对于操作,它只是抽象出经常用的4大类,分布在这4大类里的更细小的颗粒,还是要用url的方式(或者其它传统方式)来实现了。
由于head的局限性,不大可能把所有的服务都隐蔽在url之后。
至于这样的拆分,是更清晰了,还是更加混乱了,这就是仁者见仁,智者见智的事情了。
dongbin
2007-04-05
winterwolf 写道
weiqingfei 写道
rest提倡的一个观点就是uri的唯一性,对于同一内容的不同形式,以及不同动作都是通过同一个uri来完成的。把传统用uri来标识的动作,用html的head来标识。
这正是我不理解的地方. 比如order.com是一个定单服务 那么所有对定单的操作都要用一个URL! 仅仅对一个定单的操作可以仅仅用save delete update 但是如果对全部定单进行备份和查询怎么办 ?
很多服务都被荫藏在url之后 这样rest还是会变的越来越复杂 最后变成官方的ws.
一旦服务被荫蔽在url之后 其它人就很难了结服务的内容及如何调用服务. 为什么不用url来表示资源和操作用guessorder.save allorder.backup 这样不是更简单更现实吗?
winterwolf
2007-04-05
weiqingfei 写道
rest提倡的一个观点就是uri的唯一性,对于同一内容的不同形式,以及不同动作都是通过同一个uri来完成的。把传统用uri来标识的动作,用html的head来标识。
这正是我不理解的地方. 比如order.com是一个定单服务 那么所有对定单的操作都要用一个URL! 仅仅对一个定单的操作可以仅仅用save delete update 但是如果对全部定单进行备份和查询怎么办 ?
很多服务都被荫藏在url之后 这样rest还是会变的越来越复杂 最后变成官方的ws.
一旦服务被荫蔽在url之后 其它人就很难了结服务的内容及如何调用服务. 为什么不用url来表示资源和操作用guessorder.save allorder.backup 这样不是更简单更现实吗?
weiqingfei
2007-04-05
winterwolf 写道
我的理解是rest是让URL通过 put post delete updata来提供ws服务. 但是我觉得没必要非用一个url象 www.ws.com/sv1.save www.ws.com/sv2.updata 不是更方面吗
put post delete updata在rest中所对应的操作,传统上都是用put post来做的,只不过判读动作以及内容形式是由用户自己实现的,现在只不过把这个判断交给了容器来做。因为它动作,以及操作内容形式的颗粒度太粗,操作内容处于ws和html之间,动作的话也只是把mvc里的c抽象出4大类。
rest提倡的一个观点就是uri的唯一性,对于同一内容的不同形式,以及不同动作都是通过同一个uri来完成的。把传统用uri来标识的动作,用html的head来标识。
winterwolf
2007-04-04
我的理解是rest是让URL通过 put post delete updata来提供ws服务. 但是我觉得没必要非用一个url象 www.ws.com/sv1.save www.ws.com/sv2.updata 不是更方面吗
weiqingfei
2007-04-04
dennis_zane 写道
weiqingfei 写道
奇怪,rest怎么能和ws放到同一个层次上来比呢?
你了解什么是REST了吗?
REST是什么?套用一个不客气的说法,就是“新瓶装老酒”。
简单的来讲,就是把if...else....换了个地方来做,不管是内容还是动作。
dennis_zane
2007-04-04
weiqingfei 写道
奇怪,rest怎么能和ws放到同一个层次上来比呢?
你了解什么是REST了吗?
- 浏览: 1677809 次
- 性别:

- 来自: 上海

- 详细资料
搜索本博客
我的相册
游乌镇
共 33 张
共 33 张
链接
最新评论
-
mod_rails尝鲜
我觉得还是mod_fcgid(不是mod_fastcgi)实际点
-- by zgd -
mod_rails尝鲜
hostingrails也已经提供mod_rails了
-- by leondu -
mod_rails尝鲜
dreamhost已经提供mod_rails了
-- by zgd -
关于JavaEye网站未来发展 ...
期待第三阶段目标的实现,但第三目标好像类似于google的云计算,建议赶紧开发, ...
-- by selectme_2008 -
总结一下大家对JavaEye网 ...
javaeye是我比较喜欢的一个网站,但盈利模式还是比较单一,让人怀疑网站是否能 ...
-- by selectme_2008






评论排行榜