|
精华帖 (3) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-11-27
restful 是实现层的，不能简单从url上区分吧
|
| 返回顶楼 | |
|
发表时间：2008-11-27
最后修改：2008-11-27
jacky.jihao 写道 restful 是实现层的，不能简单从url上区分吧
如果URL真如诸位所言那么无足轻重的话，fielding博士的论文里也没必要用那么多篇幅去描述URI了。 要说一个设计如何如何的好，我认为首先就是要遵守形式上的约束，况且这个形式是与实质有必然关系的。就如同XML，我的一堆标记设计的再好，描述能力再强大，如果写出来的文档不是well-formed，解析器根本就不认。 当然在企业软件领域，很多时候很难设计出一个格式漂亮又能表达意图的URL，比如一个GET，往往参数一堆，没法组织。 这只能说明REST在这样的应用中不适合，而不是说为了把REST套进来，URL的格式就可以忽略。 |
| 返回顶楼 | |
|
发表时间：2008-11-27
最后修改：2008-11-27
hozaka 写道 我并没有针对楼主或者某个人的意思，如果引起大家的误解我可以道歉，只是对事不对人而已。
举个实际的例子，比如 http://www.example.com/findProduct?id=1 这样一个 url，就不 REST 了吗？不一定，只要这个地址能根据不同的 request method 执行不同的过程，就是 REST。 我的观点：REST 的精髓在于资源，而不是 URL，更加没有限定URL的形式。不在于表象，而在于资源的内部，即如 REST 字面意思所描述，发生迁移的，是 server 端的状态；变化的表象，是客户端的结果；改变的手段，是通过 URL，在这里，仅仅是作为一个入口，仅此而已，至于形式，在这个过程中是无所谓的。 其实这个例子， 根本没法说明你RESTFUL了。 从这个URL分析，http method是GET，无论我RESTFUL与否，都是GET, 有什么区别么？ 而且从这个URL看不到任何资源的概念，怎么让人相信你就是RESTFUL了呢。RESTFUL提供了一种以名词(资源)为中心的建模思路，所有的动词语义都用隐藏在背后的HTTP get, put, post, delete来表达，而不是显式的find什么，add什么。 形式自有其必要性， 况且这个形式与本质是紧密关联的。如果不能用一个适合的URL来表述资源，那么肯定存在如下两个问题之一： 1. 在不适合RESTFUL的业务场景下使用了REST 2. 对资源的抽象，理解和组织有问题 |
| 返回顶楼 | |
|
发表时间：2008-11-27
恰恰相反，举这样一个在很多人看来没办法说明REST的例子，正是我的本意。
引用 从这个URL分析，http method是GET，无论我RESTFUL与否，都是GET, 有什么区别么？ 首先，光从一个URL是没有办法断定所谓GET还是POST，或者是PUT,DELETE,HEAD等等，即使是我所举的这样一个例子，只要能响应POST,PUT,DELETE等method，就是REST所表述的状态了。 其次，大家都认同的一点就是，REST 指导的是一种思路，而不是一种具型的风格，那么何必在乎别人怎么看？别人一看能明白是一个resource，固然不错，但看上去不像有如何？我的观点阐述的很清楚，这是 friendly url 的范畴，与表象无关，与状态迁移无关。 最后，假如是 http://www.example.com/a?id=1 又如何，更加不像了对吗？但是一样能用，一样能很 RESTful 的操作对应的资源。突然想到一个更加好的例子，哪就是 *URI* 本身，互联网上资源的标识，是完整的 URI，而不是其中的 products 或者是 id，是一个整体。至于这个标识好不好读，什么形式，不会有本质的影响，论文中提到这一点，是为了阐述这个概念，而不是说明“形式很重要” |
| 返回顶楼 | |
|
发表时间：2008-11-28
我一直以为RESTful的优势在于架构无状态……
|
| 返回顶楼 | |
|
发表时间：2008-11-28
hozaka 写道 恰恰相反，举这样一个在很多人看来没办法说明REST的例子，正是我的本意。
引用 从这个URL分析，http method是GET，无论我RESTFUL与否，都是GET, 有什么区别么？
首先，光从一个URL是没有办法断定所谓GET还是POST，或者是PUT,DELETE,HEAD等等，即使是我所举的这样一个例子，只要能响应POST,PUT,DELETE等method，就是REST所表述的状态了。 其次，大家都认同的一点就是，REST 指导的是一种思路，而不是一种具型的风格，那么何必在乎别人怎么看？别人一看能明白是一个resource，固然不错，但看上去不像有如何？我的观点阐述的很清楚，这是 friendly url 的范畴，与表象无关，与状态迁移无关。 最后，假如是 http://www.example.com/a?id=1 又如何，更加不像了对吗？但是一样能用，一样能很 RESTful 的操作对应的资源。突然想到一个更加好的例子，哪就是 *URI* 本身，互联网上资源的标识，是完整的 URI，而不是其中的 products 或者是 id，是一个整体。至于这个标识好不好读，什么形式，不会有本质的影响，论文中提到这一点，是为了阐述这个概念，而不是说明“形式很重要” 其实你的理解和思路跟阿里软件是一样的，他们提供的据称是RESTFUL的OPEN API都是这样的: http://....../sip?apiName=&appId=&nick=&fields=&................ |
| 返回顶楼 | |
|
发表时间：2008-11-28
URL对资源的描述的合理程度，如同你写代码的变量命名，好与坏不会影响执行的结果，但是会妨碍别人理解代码。
|
| 返回顶楼 | |
|
发表时间：2008-11-28
javaeye_fan 写道
kaven 写道
dennis_zane 写道
hozaka 写道
没必要一味的死扣 RESTful 的概念，好像全世界的 rails 应用非要 REST 不可。有这个时间去窥视 URL，还不如花这点时间去真正理解一下什么叫做 REST。
顺便提一下，REST 早在 rails 以前很长时间就已经有了，有兴趣的可以去查 HTTP 协议的历史，多学习一点背景知识，没必要纠结在这种表面问题上 - 居然已经到了死抠的地步了 恩，您很牛。我比较无语的是，我个人的一个小小疑问，您能扯这么远，您从哪点看出我死扣REST了？是你的好为人师吧。 没有高超的javascript技能，很难完全用RESTful，所以完全的RESTful对rails来说是件很简单的事情，但是对javascript要求太高了。
无知者无所谓，javascript和restful连1分钱的关系也没有！而且ajax容易破坏restful的原则
ajax怎么就容易破坏restful原则了？ 如果没有ajax，浏览器端如何put，delete？ |
| 返回顶楼 | |
|
发表时间：2008-11-28
hozaka 写道 没必要一味的死扣 RESTful 的概念，好像全世界的 rails 应用非要 REST 不可。有这个时间去窥视 URL，还不如花这点时间去真正理解一下什么叫做 REST。
顺便提一下，REST 早在 rails 以前很长时间就已经有了，有兴趣的可以去查 HTTP 协议的历史，多学习一点背景知识，没必要纠结在这种表面问题上 - 居然已经到了死抠的地步了 不错,至少告诉我们应该跳出Rails来理解REST.这个我觉得还是很有必要的. |
| 返回顶楼 | |
|
发表时间：2008-11-28
tianhen 写道
javaeye_fan 写道
kaven 写道
dennis_zane 写道
hozaka 写道
没必要一味的死扣 RESTful 的概念，好像全世界的 rails 应用非要 REST 不可。有这个时间去窥视 URL，还不如花这点时间去真正理解一下什么叫做 REST。
顺便提一下，REST 早在 rails 以前很长时间就已经有了，有兴趣的可以去查 HTTP 协议的历史，多学习一点背景知识，没必要纠结在这种表面问题上 - 居然已经到了死抠的地步了 恩，您很牛。我比较无语的是，我个人的一个小小疑问，您能扯这么远，您从哪点看出我死扣REST了？是你的好为人师吧。 没有高超的javascript技能，很难完全用RESTful，所以完全的RESTful对rails来说是件很简单的事情，但是对javascript要求太高了。
无知者无所谓，javascript和restful连1分钱的关系也没有！而且ajax容易破坏restful的原则
ajax怎么就容易破坏restful原则了？ 如果没有ajax，浏览器端如何put，delete？ 两种方式:1.浏览器原生支持 2.替代方案(可以借鉴RoR的重载的POST方法或者在http头标记) ajax还真和REST没关系,你要搞清楚,REST是一组设计约束,不是某种具体实现,不要和某种具体技术挂钩起来 |
| 返回顶楼 | |
