REST的意义在于：

刚才回了qiezi的一篇帖子，发现回到他的blog里去了，不如新开一篇：



如果能够套用CRUD，那么REST就是既能提供数据(或者用REST的术语:resource)又能提供页面。

GET  /posts        # list,   for display only  
GET  /posts/new    # new,    for display only  
GET  /posts/1;edit # edit,   for display only  
POST /posts        # update, for resource  
GET  /posts/1      # view,   for both display and resource  
PUT  /posts/1      # update, for resource  
DELETE /posts/1    # destroy,for resource 

为什么CRUD好，除了可以理清思路，更是为了可以用REST标准来创建一套既能...又能...的机制。这样为你的网站/程序自动提供API了。

设想REST流行起来，新网站都缺省地提供符合REST标准的API，整个internet就是一个巨大的类库，这才是真正的webOS。这才是REST的魅力所在，是激动人心的地方，不是仅仅为了某单个项目的优化。

再引申以下：
web calendar，web office，web mail，web rss reader都有些很不错的小公司提供的服务，人气也不错，但是google开始做这些东西的时候，他们就消失了(或者被google收购了)。因为虽然功能有些差距，但google把他们集成了呀。集成的便利性很有诱惑力，所以那些focus的小公司就无以为继了。有人说google是下一个microsoft，只不过把东西都搬到网上去了，这个垄断的趋势已经有苗头了。但是如果那些service provider都用REST的标准，就像上面说的，internet就是一个巨大的类库（就像DHH的那个ppt的名字：world of resources），那么垄断就不那么容易了。我们程序员也能得到更大的自由，册那，那是多么大的自由啊。我还能记得当我学会用vba控制ms office的喜悦。我用更大的喜悦期盼着这个world of resources。

如果从这个角度来理解CRUD的意义，是不是就简单一些了？再读一下Nested Resource的描述和定义。然后闭上眼睛想一想MFC，MSO（office库）或者你用过的任何API，他们是不都是resource或者nested resource的crud啊？操作系统都是crud接口的，什么不能呢？也许，你的某一个应用crud的不顺，我也不鼓吹所有的都要crud。人家说crud很伟大，为什么？要从world of resource来理解。

顺便说一句，vba是ms最好的macro语言。无疑，ruby是internet最好的macro语言。

REST是不是MVC三部分去掉了View？
REST=M+C，这样认为是否正确呢？

如果顺着这个往下扯，就又到了语义web那一套去了。在动词方面，REST充其量规范了粗粒度的完备动作集合中各元素的语义,但也仅仅是粗粒度的，否则，光update一块，就可以细分出无数的差异动作来.
而要实现"整个internet就是一个巨大的类库"，至少还需要对名词(数量海了去了)的语义做一个标准才行。

我理解语义网的目的是让计算机懂得更多，施惠于用户。而所谓internet类库，是让程序员获得更多资源，施惠于开发者。

粗粒度对的，但是有了它就能做不少事情了，细粒度的动作不就是各个resource的update组合起来吗？

我理解的REST是：M+C for resource，M+C+V for display，而REST把for resource的MC和for display的MC整合起来了。

我怎么感觉REST相当于把数据库暴露出来，当然具有很大的灵活性了。但是代价是，把编程任务从server端转嫁到调用者那里去了，总的工作量并未减少，好处是灵活性。这种讲法不知各位如何看法？

对于REST的实际意义，我是这样认为的：

1、克服了MVC框架中Action/View代码膨胀过多的问题
2、解决了Web层代码重用的问题(MVC无法重用，而组件框架JSF/Tapestry粒度太大)

希望以后有个实际一点的例子来讨论，这样一来比较容易理解，二来也容易发现问题。

REST跟MVC！？哪儿跟哪儿啊。
REST是为了提供大规模并行而提出的一种设置准则，其基本特征就是把资源（常量性质的和幂等性质的）不断的cache形成体系。为了做到这一点，把变动的放到最终的客户端而已。这个跟MVC有什么关系呢？
对于资源的操作，我们抽象出CRUD，正好可以用HTTP的PUT GET POST DELETE来对应，而这些操作原语本质上跟REST没有什么关系，虽然REST几乎是完全倾向于如此。
我觉得现在的问题是：URI（或者IRI）表达资源仍然没有考虑清楚，尤其是Ajax风格开始流行以后，mashup要求我们不仅仅用URI表达我所获得的整个资源，而要用URI表达组成整个资源的各个部分资源，它们或许来自不同的地方。但是我们的WebClient仍然只能为一个整体资源指定一个URI。
扯远了……

页面和数据有什么无法跨越的鸿沟？页面不就是为了把数据向人展现的一个数据的视图？为什么能提供数据就不能提供页面？我怎么总觉得有了数据，你愿意提供页面不愿意提供页面都只是一个无关宏旨的细节性的决策而已呢？