宣称支持REST的Web框架到底有多REST？
目前，有不少Web Services平台与应用框架都对RESTful服务提供了不同程度的支持。近日，Stefan Tilkov撰写了一篇文章，列举出了一系列标准，可以作为评估这些框架与平台的起始点。
他认为，从较高层次上来说，必须问的问题有（回答“是”的越多，框架越接近于理想的REST Web应用框架）：
- 框架是否遵守一条HTTP消息并非仅仅包含一个URI的原则？也就是说，分发是不是至少要基于HTTP谓词、URI、Content-type与Accept headers呢？
- 可否使用同样的业务逻辑在响应中返回不同的内容类型呢？
- 是否支持对条件请求的检查呢？
- 如果后端逻辑没有设定，是否会自动计算ETags呢？
- 作为框架的使用者，是否能够轻松读取所有的HTTP请求头信息呢？
- 是否可以轻松设置所有的HTTP响应头信息呢？
- 是否可以使用客户化的HTTP谓词？
- 是否能够清晰、简单地在响应中返回正确的状态码，框架会正确使用这些状态码么（如果使用的话）？
Mike Amundsen建议向REST Litmus Test for Web Frameworks列表中再增加一些内容，他认为URI的各个组成部分、路径与查询字符串的作用是一样的，都可以将资源彼此区分开来。他援引了Roy T. Fielding on REST-Discuss, 2002：
[F]或是服务端构建的URI，查询字符串与路径信息之间并没有明确的区分——他们都可以区分资源。
下面列举出一些支持RESTful服务的知名Web框架：
Java
.net
Ruby
Python
说出你的想法吧，这样我们才能不断更新这个构建RESTful服务的框架、平台列表，一定要看看原文了解详细信息。
