传统的Java Web MVC框架距离REST有多远

到目前为止，传统的Java Web MVC框架（Struts、WebWork、Spring MVC、etc.）还无法很好地支持REST风格的架构设计。它们在设计之初时基本上都是围绕着基于HTML表单的交互模式来设计的，View的粒度难以达到单个页面以下。不能把响应Ajax请求而返回的XML/JSON/纯文本格式的数据简单地认为是Web MVC框架中的View，实际上这个时候这些数据的语义已经与传统的Web MVC架构中的View的语义相距甚远。

传统的Web MVC框架一个最大的问题是它们看待URL的方式与REST有很大的差别。REST把服务器端所有的URL都当作是抽象的资源（相当于是面向对象设计中的接口），虽然Web MVC也强调不应该将硬编码的URL（例如：http://www.xxx.com/yyy/zzz/abcd.jsp）直接暴露出来，而应该通过某个Controller来暴露，将这个页面配置为Controller的一个View，但是Web MVC框架并没有有意识地将URL当作抽象的资源来看待和设计。

还有一个较为严重的问题是传统的Web MVC框架基本上都只支持GET和POST两种HTTP方法，而不支持PUT和DELETE方法，而Servlet API是支持上述所有的HTTP方法的（支持doPut和doDelete方法）。

举个例子，Spring MVC所支持的HTTP方法封装在org.springframework.web.servlet.supportWebContentGenerator类中，其中只有METHOD_HEAD、METHOD_GET、METHOD_POST几个常量，而没有METHOD_PUT、METHOD_DELETE，显然其作者并不认为有必要支持HTTP的PUT和DELETE方法。

我没有考察过Struts和WebWork，估计结果应该是一样的，而且也没有听说过Strust和WebWork的作者有支持REST风格架构设计的计划。JSF呢？虽然Gavin King以前在某地说过JSF完全可以支持REST，上次见面我没有仔细向他请教这个问题，但是可以肯定的是JSF从来就没有把支持REST风格的架构设计作为他们的核心目标之一。

所以在这个方面，Java社区要比Ruby社区落后很多了。目前只能脱离开传统的Web MVC框架，基于Servlet API来建造一个符合REST要求的新的服务器端架构（当然，Spring IoC、Hibernate等框架仍然可以保留）。好在不需要我们亲自来做这个事情，已经有一些Java的服务器端框架可以支持REST了。例如：Restlet（http://www.restlet.org）。另外还有一些横跨浏览器和服务器的设计模式可以利用，详情见《Ajax模式与最佳实践》。

URL的问题很容易解决 任何现有的传统的开发框架都能做到

<map:match pattern="www.rest.com/*">

<map:generate src="http://php.com/cgi-local/page?index_{1}"/>

<map:transform src="rest.xsl"/>

<map:serialize type="xml"/>

</map:match>

rest提到的四个方式也没必要都用 只用post就可以 将操作放到post发送的data里面

URL的问题很容易解决 任何现有的传统的开发框架都能做到

<map:match pattern="www.rest.com/*">

<map:generate src="http://php.com/cgi-local/page?index_{1}"/>

<map:transform src="rest.xsl"/>

<map:serialize type="xml"/>

</map:match>

rest提到的四个方式也没必要都用 只用post就可以 将操作放到post发送的data里面

不是有办法解决URL的问题就足够了，这两类框架它们的设计目标有非常大的差异。
传统的Java Web MVC框架的目标主要是为了在服务器端分离表现逻辑和业务逻辑。也就是说，它们还是假设表现逻辑是完全分布于服务器端的，它们将客户端看作是瘦的，除了做页面的render，几乎不存在任何执行逻辑。

而支持REST的框架的目标主要是为客户端提供REST风格的Web服务。也就是说，它们假设表现逻辑分布于客户端，它们将客户端看作是胖的。

用一些原本设计来支持瘦客户端的Web框架，来支持胖客户端，感觉是很别扭的。

做REST风格的架构设计，只支持GET和POST方法是肯定不够的。

注意，我只是在说传统的Web MVC框架，不包括Cocoon在内。

cetia4 一个REST FULL的MVC框架,

不过我觉得在REST下面,要根据CLIENT的Accept Content Type和

提交方法来确定操作还是比较麻烦的,当然可能也是因为自己还不太习惯。

感觉现在的REST有点像当初一开始的领域模型，拼了老命去实现，搞到最后发现思想最先进的不一定是最好的。

领域模型现在有什么不好的？我用RoR写领域模型爽的很。

上面的例子说明 一个普通的php应用可以被包装成rest web service. cocoon什么也没做只是调用。

在后面工作的是php jsp asp cgi 这些老系统。如果用cocoon做中间层 那么现有的平台都可以变成rest风格的。

这个和传统框架不冲突。就2点区别

1
原来 从数据库取数据用html格式发布
现在 从数据库取数据用xml格式发布

2
原来的html可能是多个返回数据拼的 里面还包括乱七八糟的url
现在简单了xml可以是单一的数据。其他的交给中间层（web service聚合器）

web service聚合器---cocoon
加工成view片段并附加fuction的工作可以由xslt来做  拼view的工作由ajax安排

to winterwolf：
我不知道你有没有亲自用过这些Web MVC框架。如果瘦客户端已经足以满足要求，那么这些框架也就够用了。当用户希望获得更好的交互体验时，这些框架本身并没有为此提供很好的支持。说到REST风格的架构设计，这些Web MVC框架对于REST来说相当于是鸡肋，没有必要加入这些框架带来额外的复杂性。

至于说到你很推崇的Cocoon，我不喜欢它的主要原因是它强迫程序员按照一种以XML为中心的视角来做开发，而不是促进了面向对象的开发，Spring可以促进程序员更好地以面向对象的方式来做开发。

对于REST风格的架构设计来说，因为它跟Web Service类似，最重要的是服务接口的设计（在REST这里就是抽象的URL），因此REST不是很在意服务器端内部是以XML为中心还是以面向对象为中心，也不是很在意服务器端内部是否是分层的架构。Cocoon也许对于REST的支持会比传统的Web MVC框架要好，但是使用Cocoon是要付出相当大的代价的。