Java REST框架一览

xfire也支持吧？
非常感谢楼主的分享和分析！

sun的web service框架也支持吧，好像jdk6就有带

http://www.infoq.com/cn/articles/rest-architecure
一篇非常好的介绍REST框架的文章 REST框架非常好
支持

dlee关于服务器的抽象基本同意，不过我宁愿更泛化的说其实是通信主体之间互相的抽象模型，其实说到底，分成两种不同的抽象，一种是资源模型，一种是功能模型（不管是基本的RPC还是基于分布式对象的RPC），而这两种模型其实是可以互相替换的。

资源模型中，由于CGI的引入已经可以代替功能模型了，而功能模型模拟资源模型也不是很复杂。那么这两种模型究竟有什么优劣之分呢？

我认为，本质上它们并没有什么大不了的区别，而它们最大的差别在于视角的不同，当然，由于立场的不同，会导致对于同样的情形其理解的复杂度却不同。比如：由于REST对于无状态的专注，导致它对于大规模分布式系统比较合适，为了做到这一点，它尽量认定资源是常量性的或者是幂等性的，因而，也就是可以缓存的，由于缓存的存在，它可以几乎无限制的提高其并行性。这也是HTTP协议最初考虑的重点之一。

一般来说，单独讨论REST或者SOAP本身没有太大的价值，一般情况下，我们愿意把mashup和REST合起来讨论，mashup在客户端被称为Portlet（MS又把它叫做WebPart），它是一种把多个微资源整合成一个单独的资源视图的一种技术，由于这种技术的存在，REST显得更有战斗力，更像是一种可以跟别的功能模型竞争的一种模型。而这里面主要牵扯到两方面的问题，一个是URI，一个是Ajax，这个整合的资源的URI应该是什么呢？整合资源的各个分资源在整个结构中各自负担什么角色，怎么实施部分资源的异步的修改和替换。这种以资源和资源的组合为核心和模型的通信方式，对于大多数人和大多数环境都是容易理解和容易想象的。对于这个模型所依赖的Runtime，其客户端的主要Runtime现在还缺乏基本能力，比如：现在大多数Browser都只支持HTTP协议的GET和POST，而对于PUT和DELETE的支持都很差甚至没有，而服务端Runtime的能力倒是容易改进。HTTP确实规定了一个认证和安全的元模型，但是对于具体的认证技术和机制并没有具体的规定，也就是说，在认证和安全方面，其实现比基于功能模型要落后一些。

to fixopen：
我觉得如果这样来理解，会更加容易，而且很简明。

RPC对于服务器的建模方式，类似于Martin说的“事务脚本”，是以动词为中心来建模的。“我要做A事”、“我要做B事”。要做什么事情很明确，但是由谁来做这件事的主体并不明确，很多时候全部使用一个唯一的URI。造成了这个URI的语义过于丰富，无法全部用标准的HTTP方法和HTTP头信息字段字段来表达，那么怎么办呢？消息体也用上吧。且慢，REST有一个重要的架构约束就是HTTP操作语义的可见性，操作语义用消息体来表达了，还有可见性吗？

REST对于服务器的建模方式，类似于Martin说的“领域模型”，是以名词为中心来建模的。“张三去做A事”、“李四去做B事”。首先要明确做某件事情的主体，这个主体其实就是一个资源，使用一个特定的URI，然后再确定此主体可以执行的操作。这件事情应该由谁做很明确，而这个主体要做的事情也不多，基于标准的HTTP方法和HTTP头信息字段足以表达，不需要用到消息体，因此REST的操作语义的可见性的架构约束也就能够满足了。

操作语义的可见性有何重要呢？先卖个关子，各位读了论文，自然会得到答案。

REST架构风格并没有试图掩盖这些差别，而是将服务器抽象为一组离散资源的集合。资源是一个抽象的概念，而不是代表某个具体的东西。注意：要真正理解REST，就一定要增强自己的抽象思维能力，充分理解到资源是抽象的。如果完全不具有抽象思维的能力，一定要将资源与数据库中的一张表或服务器端的一个文件（HTML、Servlet、JSP、etc.）一一挂起钩来，就无法真正理解REST了。资源是名词性的，因此REST建模是以名词为中心的。

上述是目前基于网络的应用的主要的三种抽象方式。这三种不同的抽象方式会严重影响客户端与服务器的交互模式，而不同交互模式的交互效率差别相当大。分布式对象的交互模式很多时候效率很低，因为掩盖了分布式对象与本地对象的差别，很多时候都会导致细粒度的API（需要一再强调才能让一些不明就里的架构初哥按照正确的方式来做设计）。实践已经证明，与RPC和分布式对象相比，REST是一种对于服务器更加有效的抽象方式，将会带来粒度更大和更有效率的交互模式。这样的效果与Fielding设计REST的初衷是吻合的，REST就是专门为交互的性能和可伸缩性进行过优化的一种架构风格。而SOAP在设计的时候优先考虑的从来不是性能和可伸缩性，而是互操作性。除非出现奇迹，否则你种什么，就应该长出来什么。你种的是瓜，长出来的就是瓜；你种的是豆，长出来的就是豆。

我个人觉得要做rest 没必要兼容servlet 如果基于servlet 那么实现也只是一种表象

同意DLEE的说法，同时，我认为其中提到了一个重要的而我故意忽略的东西，语义的显明性和可见性。

当然，所谓的显明性，可见性，显然也依赖于我们的立足点，我们总是会认为离我们近的东西更清晰。

如果我们对于HTTP本身有深入的理解，我们自然会觉得REST充分利用了它的能力，很轻松很自然的表达了我们需要表达的东西，但是如果我们对于HTTP的理解仅仅是GET和POST，那么我们显然会觉得SOAP或者类似的别的RPC方案很自然，一个是获取，一个是提交，获取什么和提交什么都是通过URI+Parameters来实现的，Parameters可以通过QueryString，也可以通过POST EntityInfo。似乎也没有什么难于理解的不够清晰的地方。

也就是说，语义是否显明清晰可见，依赖于我们的知识体系，如果我们觉得某种东西清晰，不用担心，你的感觉是对的。

不过，纯从逻辑的角度，RPC的方案重复了HTTP已经考虑并且实现的功能，显然是一种功能冗余，而REST没有重复实现HTTP已经实现的功能，只是简单的重用了HTTP的能力。这显然比RPC的方式好很多，RPC只是把HTTP作为一个简单的单纯的传输机制来使用。

Fielding在论文中根本就没有这样抨击过WebDAV，而是从正面表扬WebDAV是一个行为良好的扩展。这说明你根本没有看懂Fielding的原文，你的英文程度很差。WebDAV开发恰好我前些年也做过，WebDAV是把HTTP4种动词都用上了。WebDAV是面向服务器端的文件系统的，它是将资源映射到服务器端的文件系统。你并不懂WebDAV，为何还要在这里卖弄呢？

你的目的莫非就是为了证明：其实Fielding并不懂RPC，我Lordaeron要比Fielding更懂RPC，甚至比Fielding更懂HTTP？
其实谁比谁更懂HTTP我并不是很关心，我们翻译这篇论文也是想为了给大家提供一个方便，让大家不至于被某个歪嘴和尚误导。但是你这样明目张胆歪曲Fielding的观点，我却感觉有点愤慨了。

   按照论文中的观点，现代Web是按照REST风格设计的系统，而HTTP是Web中的一部分，因此你的这段话是有问题的。另外HTTP不是传输机制，文中也单独做为一个大标题。
   REST是分布式架构风格，Web是它的一个成功案例，RoR或许也是（不了解RoR，但是看大家讨论REST总会提到使用RoR如何实现的），但是REST不是具体的技术，就像作者所言，他是一堆架构约束的集合。