REST-*组织

JBoss已在月初的JBoss世界大会上正式宣布了它的新项目“REST-*”。

REST-*试图从以下几个方面将自己和WS-*区别开：

WS-*是一组很好的规范，它们定义了实现基于网络的中间件服务所需要的各种协议和信封格式。尽管比起CORBA它已有很大进步，然而它仍然存在一些缺点，而这些缺点正是REST-*试图解决的。主要是：

WS-*不利用HTTP：WS-*使用HTTP作为传输协议。WS-*服务主要使用HTTP作为连接建立的机制，却忽视了其它丰富且久经考验的特性，而正是这些特性促使了Web的成功……由于我们集中关注RESTful原则，所以我们提出的规范将会完全利用HTTP协议的优势，而不是重新发明自己的技术。

WS-*入门的门槛高：WS-*协议栈难于实现，并且，客户端和服务端都要使用复杂的协议栈……我们希望最大限度地降低这套规范的入门门槛。

WS-*依赖于信封格式：WS-*协议栈依赖于SOAP，所有WS-*发送的消息都要遵循信封格式……而HTTP消息已经足够完善，它很简单、健壮、而且非常灵活。

该项目的架构目标是：

低入门门槛：对使用该规范的用户，入门门槛应该足够低。他们应该不需要为了使用规范而安装任何库或者软件包……

通过扩展去描述边界情况：边界情况可能是使得主规范变得复杂的原因之一，它应该描述在一个独立的子规范中，并将它们放在主规范之上。

实用REST：当某规范致力于遵循RESTful原则时，简单性的要求绝不该让步于纯粹的RESTafarian。如果你要使用REST的原则创建更简单的设计，那么这就是你应选择的路。

80/20原则：规范应该保持简单……它应该覆盖80%的常用情况，而边界情况不应该出现在主规范之中……

避免信封格式：只要有可能，就应该避免信封格式……信封格式倾向于在HTTP上打通一个隧道，而不是直接利用HTTP……大多数情况下，HTTP头在传输请求，响应和资源的元数据方面已经足够。

不要扩展数据格式：如果可能，规范就不应该定义新数据格式

根据大会的宣布，JBoss试图建立一个类似于JBoss.org的完全协作的社区，而不是由提供商驱动，为提供商服务的社区 。他们设想着通过开源的方式：

……定义新协议……但是整个这事情的重点之一是记录人们以 RESTful方式工作（包括HTTP和非HTTP）的指导意见和最佳实践，这可能包含安全，管理等。

（顺便提一下，上述引自Mark Little的一段话已经相悖于前面提到的架构目标，因为他提到新协议以及非HTTP的支持。）

Mark认为：

如果最后我们的结果的是一个聚集器，包含指向解决这些那些问题的“标准”方式，那么这已经是一个成功的产出了……开展该工作的原因是因为社区需要它。人们不断提出相同的问题， 虽然有很多书，以及该领域的专家回答了问题，但却没有清晰的答案。在某些情况下，我们可能得到许多不同的答案。这意味着答案不存在吗？不然。然而如果是真正理解REST的人都不同意的答案，对于那些只求使用REST的人来说有何意义呢？这就是REST-*要做的：将社区联系起来，试图产出一些指导原则，当人们需要答案时就有地方可以找到它。

尽管这个新项目试图远离REST和WS的争论：

REST和WS-*孰优孰劣已经在很多文章，博客以及公开邮件列表中争论了很久。这里我们不想再重述那些争论，欲了解更多信息，请在Google上搜索“REST vs. WS-*”

不过，它还是通过引用WS*的一些特性有效地进行了比较，比如，它试图表达WS*很重，而REST是轻量级的。然而，两种标准都可以“手动”实现，（假定都是用HTTP传输的话，）所需的代码量是相同的。再者，一个支持自动混编/拆散以及消息路由的运行时，所包含的代码量也是相同的（比如，RestEasy——它是一款不错的框架，发布版只包含38个jar包）。如果在相同抽象层进行比 较的话，所需的代码两是相同的。讨论该问题的邮件列表还在继续。

因此，毫无疑问，REST*的宣布引起了很多回复，Steve Jones在他的博文REST-*，你能否快成熟中总结得很 好：

REST-*项目的最后产出可能是记录现有的经验，这其中的挑战之一是，很多人并没有真正理解REST是什么，所以当他们要构建更高层的类系统以及实现跨组织间的互操作时，自然会很痛苦 。一部分原因当然来自预付款协议以及迟早验收等方面的问题，但还有一部分原因看起来像是纯粹的势利或者是某些人不愿意分享那些晦涩的知识。

他继续说道：

如果REST是达摩克里斯之剑，能够洞穿现今企业集成的挑战的话，那么记录下这是如何实现的以及相关标准（使让人们更清楚地了解如何进行开发）有什么问题呢？更重要地，人们（比如SAP 或Oracle）可以通过标准的方式创建REST接口，使得服务可以很容易地被其他提供商的解决方案所使用。这个项目可以决定是否要用WADL，以及Atom和AtomPub是否能覆盖所有的企业场景，或者最少包含所有那些重要的标准。（比如，我们不再要对应于于可恶的WS-TX的REST-TX）

不论是REST还是WS，都有其实际的应用场景。问题不应该是哪个更为优越，而应该是他们如何共存，以及在特定场景下谁更合适。另一个重要的方面是不管它们多强大，都要确保所进行的比较是基于有缺点的， 而不是信仰。WS*创建了很多有价值的标准和模式，那想想这些模式能否能应用于REST是否更有意义呢？

查看英文原文：REST-*.org