|
精华帖 (10) :: 良好帖 (3) :: 新手帖 (5) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-05-11
unsid 写道 另外，所谓“惯例优先”，到底有多少惯例可通用呢？
Martin Fowler对业务逻辑的定义是“业务逻辑就是没有逻辑” /blog这个词很快就会被遗忘，然后为维护日益膨胀的“单词表”而困苦 实体是有限的，就像你建立的表是有限的，而业务逻辑比较多，而按照Fielding博士的论文，URI表示的是语义，因此好的URI应该可以很好的维护这种语义关系。我觉得，具体做法可以是用Kent的CRC卡，把上面的话直接变成URI。 |
| 返回顶楼 | |
|
发表时间：2009-05-11
sslaowan 写道 unsid 写道 另外，所谓“惯例优先”，到底有多少惯例可通用呢？
Martin Fowler对业务逻辑的定义是“业务逻辑就是没有逻辑” /blog这个词很快就会被遗忘，然后为维护日益膨胀的“单词表”而困苦 实体是有限的，就像你建立的表是有限的，而业务逻辑比较多，而按照Fielding博士的论文，URI表示的是语义，因此好的URI应该可以很好的维护这种语义关系。我觉得，具体做法可以是用Kent的CRC卡，把上面的话直接变成URI。 理论是没啥问题，开发个原型，秀一下~~ |
| 返回顶楼 | |
|
发表时间：2009-05-11
shiren1118 写道 sslaowan 写道 unsid 写道 另外，所谓“惯例优先”，到底有多少惯例可通用呢？
Martin Fowler对业务逻辑的定义是“业务逻辑就是没有逻辑” /blog这个词很快就会被遗忘，然后为维护日益膨胀的“单词表”而困苦 实体是有限的，就像你建立的表是有限的，而业务逻辑比较多，而按照Fielding博士的论文，URI表示的是语义，因此好的URI应该可以很好的维护这种语义关系。我觉得，具体做法可以是用Kent的CRC卡，把上面的话直接变成URI。 理论是没啥问题，开发个原型，秀一下~~ 嗯，正在做，我的毕设的一小部分 |
| 返回顶楼 | |
|
发表时间：2009-05-11
rest 比servlet好用吗/????
|
| 返回顶楼 | |
|
发表时间：2009-05-11
sslaowan 写道 unsid 写道 如果把谓语放在URI上怎么适应一个复杂的业务呢？
典型例子就是一个由任意多个选项组合成的复杂条件查询 给你看一个URI：http://www.baidu.com/s?q1=java&q2=&q3=&q4=&rn=10&lm=0&ct=0&ft=&q5=&q6=www.ibm.com&tn=baiduadv 这是百度的高级搜索 q1表示包含以下全部的关键词 q2表示包含以下的完整关键词 q3表示包含以下任意一个关键词 q4表示不包括以下关键词 rn表示选择搜索结果显示的条数 lm表示限定要搜索的网页的时间 ct表示搜索网页语言 ft表示搜索网页格式 q5表示查询关键词位于 q6表示限定要搜索指定的网站 最后的tn表示百度高级搜索 将来你要表达一个复杂一点的逻辑，需要一个很恐怖的uri才可以 另外我认为，REST与其说是一种新技术，倒不如说是一种呼吁 我觉得他是认为人们在开发系统中没有充分利用http原始语义或者URI本身的定位作用 而靠应用期去造轮子，其中某rest的忠实拥蹙认为“你如果用get提交一个删除服务器文件的请求是不可原谅的” 他们认为服务器行为完全可以定义在url中，而在服务器上少维护一个解析行为的过程 |
| 返回顶楼 | |
|
发表时间：2009-05-11
然而，我除了认为“一目了然的路由过程”以外，没看出这么做有多大收获
|
| 返回顶楼 | |
|
发表时间：2009-05-12
unsid 写道 sslaowan 写道 unsid 写道 如果把谓语放在URI上怎么适应一个复杂的业务呢？
典型例子就是一个由任意多个选项组合成的复杂条件查询 给你看一个URI：http://www.baidu.com/s?q1=java&q2=&q3=&q4=&rn=10&lm=0&ct=0&ft=&q5=&q6=www.ibm.com&tn=baiduadv 这是百度的高级搜索 q1表示包含以下全部的关键词 q2表示包含以下的完整关键词 q3表示包含以下任意一个关键词 q4表示不包括以下关键词 rn表示选择搜索结果显示的条数 lm表示限定要搜索的网页的时间 ct表示搜索网页语言 ft表示搜索网页格式 q5表示查询关键词位于 q6表示限定要搜索指定的网站 最后的tn表示百度高级搜索 将来你要表达一个复杂一点的逻辑，需要一个很恐怖的uri才可以 另外我认为，REST与其说是一种新技术，倒不如说是一种呼吁 我觉得他是认为人们在开发系统中没有充分利用http原始语义或者URI本身的定位作用 而靠应用期去造轮子，其中某rest的忠实拥蹙认为“你如果用get提交一个删除服务器文件的请求是不可原谅的” 他们认为服务器行为完全可以定义在url中，而在服务器上少维护一个解析行为的过程 你再好好阅读一下Fielding博士的论文吧，关于REST API和RPC的区别，以及怎样通过操作和转移表述来完成作用于资源之上的动作，以及通过URI定位资源，而资源是一种映射。这几个概念非常重要，很显然很多REST的粉丝并不了解。另外就是从Web Service的角度去看这件事（多种客户端，以及考虑遗留系统整合以及开发给其他Partner的服务），建议阅读Restful web services一书。 其实用URI表达语义没那么恐怖，至少我的论文背景是一个大型集团级的生产和商务类项目，我觉得使用REST是合适的，简单的。 |
| 返回顶楼 | |
|
发表时间：2009-05-12
那篇论文学术性很强,很多语言高度抽象,再加上翻译过程的语义损失,很难完全看懂
但是其在第五章才真正引入"表述性状态转移"这个"专门面向网络应用的架构风格" 这很让人怀疑这个论文的主要目的是引入一种新的架构风格还是强调架构风格及分析评估架构风格的重要性. |
| 返回顶楼 | |
|
发表时间：2009-05-12
unsid 写道 那篇论文学术性很强,很多语言高度抽象,再加上翻译过程的语义损失,很难完全看懂
但是其在第五章才真正引入"表述性状态转移"这个"专门面向网络应用的架构风格" 这很让人怀疑这个论文的主要目的是引入一种新的架构风格还是强调架构风格及分析评估架构风格的重要性. 当然是后者了，你看题目。不过前面都是对后面的铺垫，我第一次觉得架构设计竟然也能像数学推导一样，觉得这种思路很好 |
| 返回顶楼 | |
|
发表时间：2009-05-12
sslaowan 写道 unsid 写道 那篇论文学术性很强,很多语言高度抽象,再加上翻译过程的语义损失,很难完全看懂
但是其在第五章才真正引入"表述性状态转移"这个"专门面向网络应用的架构风格" 这很让人怀疑这个论文的主要目的是引入一种新的架构风格还是强调架构风格及分析评估架构风格的重要性. 当然是后者了，你看题目。不过前面都是对后面的铺垫，我第一次觉得架构设计竟然也能像数学推导一样，觉得这种思路很好 这个论文需要有林巴斯他们几个在SEI写的那本软件架构风格的书作为基础才好懂,否则太抽象了. |
| 返回顶楼 | |
