REST在Web上应用的局限性。

楼主完整看过DHH很久很久以前关于REST的视频么？
里面对于format如何对应到URL里讲得很清楚啊。

   我想如果浏览器有局限，那么使用Delphi的HTTP Client或Java的URL Connection来构建Client端，充分利用HTTP协议，是否可以更好的遵循REST架构呢？更为重要的是，Fielding可以领导HTTP等项目组来设计HTTP协议，设计Web，但是他们管不了浏览器实现啊。

正解,默认的routes.rb最后那段 .:format 难道是吃素的么?
鉴于楼主的标题和学术态度,号召把它投沉算了.

其实很多人都已经在实际项目中身体力行的去应用REST了，没有讨论可能是因为大家还在探索中，没有一个很好的结论，不想拿出来说事儿。

这个是你的理解错误了，可以设置request header中的Accept属性来表示你想要那个representation，这个REST讲的很清楚。

对于这样的页面，最好的方法是用Ajax请求不同的representation。当你在浏览器中输入这个页面的url时，应该只返回一个页面框架，然后发送3个Ajax请求，分别获得pdf、image和flash，uri是相同的，Accept属性不同而已。

REST在实现资源相关的use case时是十分强大的，因为它是面向资源的，但是对于面向动作的use case就差一些，比如validate一个表单。

REST自然有它的优点和缺点，但是楼主好像没说到点子上。

to weiqingfei：
对于你的问题，有两种解决方法：
1. 通过在URI中包括格式、语言相关的后缀，例如：
http://www.xxx.com/.../yyy.xml
http://www.xxx.com/.../yyy.pdf
2. 通过在HTTP请求中包括相关的头信息字段来做内容协商，例如Accept、Accept-Language

第一种解决方法适合于你无法为HTTP请求添加头信息字段的场合。第二种解决方法适合于你能够为HTTP请求添加头信息字段的场合。

第一种解决方法的优点是相关信息都在URI中，即使将该URI通过邮件或者某种方式发给别人，别人也能得到与你相同的结果。

对于服务器端设计来说，最好不要只支持一种方法，两种都支持最好。

你可以仔细读一下《RESTful Web Services》这本书的第3章，相信你会有一种豁然开朗的感觉。

Rails 1.2中的REST解决方案也有不少问题，虽然它是目前一种很好的解决方案，但是不要把它当作REST的代名词，遇到谁不理解REST就让人家去看Rails的REST解决方案。

Rails 1.2的REST解决方案中主要的问题是与ActiveRecord和数据库绑的太死了。那个scaffold_resource的设计就是简单地将数据库表中的数据以REST方式暴露给客户端来访问。带来两个问题：
1. 很多人以为REST的资源只能是数据库表中的数据这样具体的东西。事实上，资源可以代表任何东西，它是一个完全抽象的概念，而不是一个具体的东西。对比一下接口和实现之间的关系。
当然，还可以设计出与数据库完全无关的scaffold，而且高手完全不需要依赖这些scaffold。

2. 以这种方式暴露出数据库中的数据，很难控制HTTP请求的粒度，往往造成对于服务器细粒度的访问，这对于服务器的性能和可伸缩性是很不利的。

其它的问题以后再说。Rails 2.0的实现有很大改善，我还在持续观察它的进展。

怎么又扯到ror上了？没有ror就不用REST了么？
所谓的format还不是通过一个约定的形式把资源形式通过url来表现，这和通过后缀来表现有什么本质区别。

这就是我所讨论的所谓Web应用的局限（其实就是浏览器的局限）。

总之，妥协的方法就是，无法在头信息字段来协商，就只能在url中来表现。

那有一点要说明的是，如果资源可以移动到url中来表现，那么和动作也移到url中有什么不同？
结果，又回到了传统的url设计了。

总是有一种妥协的味道。

好吧,好吧,我错了. 我说的就是通过后缀好不好?

思考下: url包含representation信息就不REST吗?即使只包含representation_type也不REST?就称之为妥协?
同样思考下REST为什么要求人们精心设计url,REST这个词的字面意思.
http传输/维持数据,除了http header(include cookie),http params, http uri,  session(http header support),还能有啥?
把session的内容,cookie的内容,params的内容,在不影响业务逻辑和编程复杂性的前提下,用/sub_path/或.jpg这样的方式表达,也是REST的思想之一,对于url可读性,scalability,cache,SEO都有好处.
不明白你说的非WEB情况下是怎么一个场景.

to dlee:
generate scaffold_resource只是个依赖DB的快捷方式.
写个controller,在routes.rb里配置上map.resource :something 它就对外作为资源了,那个命令是个快捷的误导而已.

看清楚我的回复对象了么？我不是回复你的问题。