|
锁定老帖子 主题：关于REST的一点想法，欢迎大家讨论。
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-04-17
robbin 写道 这个讨论到后面已经走题了，也许每个人对REST的理解都不同。
从rails框架对REST的支持角度来看，那么只要看一看beast项目的源代码，就可以很清楚的看出来rails对REST的理解。REST对于rails来说，毫无疑问减少了action的数量，看看beast的controllers，除了7个CRUD操作，自定义的额外的public的action很少。 对于rails框架来说，通过在POST协议之上附加额外的request参数，用来模拟PUT/DELETE，甚至各种其他自定义的操作，因此从这个角度来说，REST和AJAX没什么关系。从本质上来说，REST是简化互联网应用，提高互联网应用本身的伸缩性的，非要把AJAX扯进来，搞什么多层次结构转换，根本就是南辕北辙。 既然是ruby版的讨论，我就建议大家看看beast，Rick写的，rails框架作者之一，算是官方的rails REST demo了。 本身我认为在ruby这个范围内讨论REST就不合适，而且在RAILS下更加不合适——我们现在只能说RAILS支持REST变成，不能说REST是RAILS的基础风格之一。实际上就文件组织形式来说zope更加类似REST的要求，RAILS在这个方面还差了十万八千里。同时更加让人觉得重要的是使用REST风格将给大家带来的业务分析层面的变化，这个需要单独讨论。 另外ajoo提的问题很切中要害，实际上这也牵涉到了RAILS这些快速的快速框架的基础构造的核心部分——Route组件的问题。而我们是否有理由利用这个技术去实现REST，目前我还在考虑。 总之REST风格有太多的新元素在里面，这个需要我们展开一个全方位的多角度的讨论，这么一篇贴是肯定容纳不下的。我想这个帖子主要还是用来说明究竟什么是REST，什么不是REST。 |
| 返回顶楼 | |
|
发表时间：2007-04-17
ajoo 写道 我本身不了解rest。不过单单看这个帖子的表达，似乎觉得有点不对味。
先叙述一下我对这个文章的理解： 1。rest就是主语+谓语，主语就是resource，谓语就是动作 2。就象01是和机器说话的语言，obj.doSomething()是和javac说话的语言一样，resource/operation就是和web说话的语言。 3。在rest语言中，只有resource/operation，没有参数。 如果是这样，感觉上相当优美。只是，我的经验让我总不由自主地把resource/operation和obj.message()等同起来。两者间概念上是否相同呢？是否可以说rest语言就是一个dynamically typed的OO语言？是一个每个message都没有参数的语言？ 可是，这样真的够用了么？一个纯粹的树形结构组织出来的语言真的足够表达我们在web上要做的所有事情么？ 不错，我可以把tom.talkTo(Jack)变成session/tom/jack/talk，把add(a,b)变成addition/a/b/apply，不过这样做似乎有点自己做人肉编译器的感觉。:-) 别的我不知道，但是要我用ruby或者java设计一个库，但是不许给任何方法带参数，我只怕做不到阿。 将url的参数放到那里 ? ! www.findfood.com?a=1&b=2 可以变成 post www.findfood.com <info> <data> ........ </data> <param> <a>1</a> <b>2</b> </param> </info> |
| 返回顶楼 | |
|
发表时间：2007-04-18
如果所有对象及操作都能分割成标准的7种操作的资源，那已经是RESTful了，剩下的东西我用rails和用cgi区别不大，都可以用模板方式批量生产。
REST没有解决的问题是如何把现有的东西分割成这种RESTful的资源，它只提出了一个目标，没有提出分割标准，实际上也不大可能把这个操作标准化，而这就是软件系统最复杂的部分，所以还是需要一个非常厉害的分析员来做这个工作。 直到有一天我们造出了一个系统，把各种模型及操作输入进去，它就自动完成RESTful的分割，那么所有工作就可以完全由机器做了。程序员还要做什么？界面已经由美工做了，他们只需要很简单地把RESTful连接到界面上就行。。或者程序员还剩下的工作就是“把各种模型及操作输入进去”，如果这个系统友好一点智能一点，我们的客户就可以干这个了。 |
| 返回顶楼 | |
|
发表时间：2007-05-07
REST其实就是Web-RPC
形式上url的foo/bar对应着bar方法，foo也就是那个隐藏的this，/signin表现为static 参数作为querystring或者post中的内容出现 换句话说，REST就是一个形式方法，他使得的url一一对应了一个函数，也就是说REST本身一个泛函，REST(url)=function 这样也就得到了 m(f)=g 的形式，REST是M空间中的一个泛函，RPC也是，直接函数调用就相当于一个不动点，有m(f)=f的形式 |
| 返回顶楼 | |
|
发表时间：2007-06-03
agile_boy 写道 就我的理解来看，REST是否只是适合于WEB开发，对应以前传统的C/S或者WebService接口是否有参考价值呢？
在我看来，开发的趋势应该是更容易抽象理解，更符合一般人的思维方式才好 引用 Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.
|
| 返回顶楼 | |
|
发表时间：2007-06-03
winterwolf 写道 ajoo 写道 我本身不了解rest。不过单单看这个帖子的表达，似乎觉得有点不对味。
先叙述一下我对这个文章的理解： 1。rest就是主语+谓语，主语就是resource，谓语就是动作 2。就象01是和机器说话的语言，obj.doSomething()是和javac说话的语言一样，resource/operation就是和web说话的语言。 3。在rest语言中，只有resource/operation，没有参数。 如果是这样，感觉上相当优美。只是，我的经验让我总不由自主地把resource/operation和obj.message()等同起来。两者间概念上是否相同呢？是否可以说rest语言就是一个dynamically typed的OO语言？是一个每个message都没有参数的语言？ 可是，这样真的够用了么？一个纯粹的树形结构组织出来的语言真的足够表达我们在web上要做的所有事情么？ 不错，我可以把tom.talkTo(Jack)变成session/tom/jack/talk，把add(a,b)变成addition/a/b/apply，不过这样做似乎有点自己做人肉编译器的感觉。:-) 别的我不知道，但是要我用ruby或者java设计一个库，但是不许给任何方法带参数，我只怕做不到阿。 将url的参数放到那里 ? ! www.findfood.com?a=1&b=2 可以变成 post www.findfood.com <info> <data> ........ </data> <param> <a>1</a> <b>2</b> </param> </info> ajoo说的不是放哪里的问题吧。 你这个不是还是对资源额外附加了参数？ |
| 返回顶楼 | |
|
发表时间：2007-06-03
robbin 写道 通过URL来设计系统，这绝对是一个令人感到新鲜有趣的话题，很棒的分析，我很喜欢。
目前RoR的REST实现实际上就是REST和MVC混合方式，从实际开发角度来说，正如作者所言，很多情况难以进行资源的抽象。不过，即便如此，已经足够有革命性的意义了。 是否讲LZ的面向URL设计系统理解为，面向RESTful的资源来设计系统呢？ |
| 返回顶楼 | |
|
发表时间：2007-06-07
winterwolf 写道 将url的参数放到那里 ? ! www.findfood.com?a=1&b=2 可以变成 post www.findfood.com <info> <data> ........ </data> <param> <a>1</a> <b>2</b> </param> </info> 你这是算简化了还是复杂了？后台还得解析一把你的XML？还是要用XQuery去处理？ 没看出这样用REST有啥好处 |
| 返回顶楼 | |
|
发表时间：2007-06-07
引用 将url的参数放到那里 ? !
www.findfood.com?a=1&b=2 可以变成 post www.findfood.com <info> <data> ........ </data> <param> <a>1</a> <b>2</b> </param> </info> 我刚刚基础REST,按我的理解,如果是足够RESTful的设计，www.findfood.com?a=1&b=2这种URL，根本不会出现，也不需要考虑了，如果是根据a和b属性进行的查询的话，应该能通过a和b查到一个或一些符合条件的资源，相应的资源会有相应的ID，到最后，还是应该到了www.findfood.com/objects/search/list或者www.findfood.com/objects/99/吧。 |
| 返回顶楼 | |
|
发表时间：2007-06-13
dennis_zane 写道 AllenYoung 写道 dennis_zane 写道 REST与Ajax的结合也是个很吸引人的话题，试想由RESTful的服务端API与客户端的ajax技术的相互调用，能够产生什么样的场景？很想听听大牛的看法。 目前我还想想不出REST加Ajax会产生什么样令人震撼的场景。REST的核心是resource，而我觉得对resource的操作最后肯定是通过传统HTTP请求发送到server端的。比如写一篇blog文章，无论如何利用Ajax，最后应该用传统的HTTP POST请求发送到server以便保存。 REST和Ajax的一个比较有趣的关系是，Ajax也许可以帮助我们解决resource难以建模的问题。就像我说过的那样，对名词的抽象很直观，但是动词就比较难办。而Ajax正好可以用来处理这些动词，同时保证url不变。当然，如何使用Ajax处理这些动词也是一个可以讨论的话题，我这里只是说有这个可能性。不过话说回来，即便使用Ajax处理动词的话，如何设计Ajax请求所发送到的url仍然是一个问题。目前来看，最可能的设计还是MVC形式的。所以一个可能的测量是：对所有名词使用REST架构，对动词尽量使用Ajax实现的MVC。这样至少可以保证url看起来是RESTful的。 我对REST中资源的理解，资源也可以看成是数据，我们对服务端的操作不外乎查询数据、增加数据等CRUD操作，而AJAX对服务端带来的改变是：服务端交给浏览器的不是内容，而将是数据。由javascript去扮演传统MVC框架中C的角色，负责数据的呈现、流程的转发和跳转。robbin说过，REST可能带来的是action的重用，我觉的很有道理，例如对应于用户加入圈子这个操作，对于管理员和申请者来说这个操作本质的工作是一样的——操作User这个资源，而成功后呈现的页面或者说结果不同，传统的MVC我们是写不同的action。现在，使用RESTful风格的服务端API来做，将只有一个传统意义上的action，而最终数据的呈现可以交给javascript。说着说着我自己都觉的不是很清晰：） 由javascript去扮演传统MVC框架中C的角色是不是风险太大了一点？毕竟是客户端的 |
| 返回顶楼 | |
