InfoQ最近对REST-*.org进行了报道，文章涉及REST-*的公告以及部分社区反应，引起了许多反响。最终，部分反馈也让REST-*.org做出了些改变。Infoq有幸采访了REST-*项目的带头人Bill Burke，以进一步了解详情。
\InfoQ: 您能介绍一些自己的情况么？
\我目前就职于Red Hat的JBoss部门。我曾经从事过集群、EJB容器、AOP实现和应用服务器内核的开发。我目前正在领导RESTEasy项目，同时也在推进REST-*.org。最后，我还出版过一些书籍，今年11月会由O'Reilly出版一本关于JAX-RS的书。
\InfoQ: 是什么让您拥抱了REST？
\我拥抱REST，将其作为一种实现分布式系统的可行之路花了一段时间。当我向JBoss中的其他人以及Java社区宣传REST的时候，我常常看到了同样的爬坡斗争。一开始，我认为REST是一种以非常简单、轻量级的方式去实现平台之间和语言之间真正互操作性的方法。随着我对其了解越多，我开始意识到，除了互操作性，REST的架构原则可以让应用开发者极大地解耦服务和应用之间的互操作。
\InfoQ: 您能对最后一点详细阐述一下么？在您看来，REST如何提供了更好的解耦？
\我认为关键的原则是：RESTful系统是媒体类型和它们之间的超链接驱动的。客户端可以请求它们知道如何与之交互的数据结构。返回的数据包含客户端和服务器交互所需知道的全部信息（超链接）。当系统的新特性在线出现时，新的媒体类型可以提供额外的链接。
\我正想以此来构造我们在REST-*.org要创建的规范。在我们定义中间件服务接口时，总有大量的边界情况常常使得API变得臃肿。我期望REST-*的核心规范去关注核心资源和链接关系的定义。基本上，我想针对每个REST-*正在为之创建规范的领域去定义一个指定新媒体类型的框架和指导方针。这将让社区有大量机会去试验不同的数据格式，进而将帮助我们对核心模型进行微调。
\InfoQ: 您在JBoss World大会期间进行了一次非常优秀的演讲，试图对比SOA和ROA。您能对此作进一步的阐述吗？
\当我在1月份完成我这个JBoss World大会幻灯片的第一版草稿的时候（我已经在不同会议上使用了这个幻灯片的几个迭代版本了），我碰到了一个由Anne Thomas Manes在InfoQ发布的关于SOA治理的优秀幻灯片。她在其中谈论了在组织中部署SOA时约束的重要性。要是没有约束，管理、集成和重用服务的复杂度就会随组织中越来越多的应用上线而呈指数上升。REST谈论的内容正是定义分布式接口的约束。既然它是如此强大的解耦工具，那么在大型组织中推广它绝对是件非常有意义的事情。如果你将其和HTTP协议的普遍性结合起来，你也就可以在这个混合环境中加入真正轻量级的互操作性。
\InfoQ: 在你的很多幻灯片和帖子里，你都强调了HTTP协议对于REST的作用。你是否认为不可靠、无连接的HTTP是发生服务通信的主要媒介？
\正如Roy一再强调的那样，REST并不仅限于HTTP。那就是说，在目前这个时候，还没有其他普遍存在的应用协议可以替代HTTP来实现真正轻量级的跨平台互操作性。在新的事物出现之前，HTTP将不得不继续发挥主要作用。正如REST的布道者们说的那样，Web本身已经做得相当不错了。
\InfoQ: 你已经好几次说过，REST的主要优势是它要比WS实现轻得多的事实。另一方面，随着我们提高抽象级别，使用如JAX-RS，它的量级大大变重了。例如RESTEasy就包含了38个jars。您认为这种趋势会继续吗，REST堆栈的大小会赶上WS堆栈的大小吗？
\在RESTful环境中进行HTTP调用要比在WS-*中轻得多。主要原因在于，除了发送请求所需的HTTP，WS-*还需要一个信封格式。换句话讲，WS-*在HTTP之上还构建了其他协议。除了定义所有你的媒体类型，还需要使用WSDL定义这种WS-*协议。在REST中，你只需要定义你的媒体类型。操作和消息格式都是预先定义好的。
\尽管REST堆栈可能会变大并赶上WS堆栈的大小，但从应用的观点或堆栈提供者的观点看，它并不需要变得太复杂而难以实现。REST的解耦和动态天性结合HTTP的内容协商可以提供一种方法既使基本交互和媒体类型保持简单，同时为更复杂的协议提供了钩子，以了解新媒体和链接关系创建过程中发生的事情。
\但是，对RESTEasy得要公平些，其核心真的只有些其他Java项目也可能有的依赖：一个Servlet容器、日志API和一个HTTP客户端库。其他的jar处理RESTEasy与其他组件模型（如Spring、Guice和EJB）的集成，以及通过使用第三方流行的库（如Jettison、Jackson、James、Abdera和JAXB）来支持象JSON、XML、Multipart、Atom和XOP这样的数据格式。使用Servlet容器，你绝对没有理由不能开发RESTful服务，但是我保证你会用到我们打包的许多第三方库。
\不管怎么说，我们已经在Maven上作了大量工作，因此你可以挑选你想要包含的依赖。
\InfoQ: 很多人都认为服务互操作性的基础是预先制定契约和早期验证。您认为REST对此的答案是什么？WADL？
\不，我认为我们不需要一个和WSDL一样的东西。在REST中，互操作性是由客户端和服务器之间交换的媒体类型和链接关系定义的。换句话讲，这种交换的媒体类型就是契约。
\InfoQ: 很多人都认为REST的一个主要优点是限制了方法的数量，这意味着所要求的动作往往必须被“编码”到服务的有效负荷之内。你认为4是一个最佳的方法数吗？
\首先，在REST中，动作永远都不应该被编码到一个有效负荷之内。客户端应该将动作建模为状态。
\但是，我想你更可能是在讲REST的统一接口约束吧？SQL只有4个方法就可以建模相当复杂的交互和应用。但要回答你的问题：“PUT、POST、GET和DELETE是否就够了？”我认为对于大多数系统来说它们就够了。我还认为有可能需要“OPTIONS”，它可以用于服务描述。当你有客户端只想通过链接将资源彼此链接时，“LINK”和“UNLINK”可能会有些有趣的用例。
\InfoQ: 那么REST-*背后的目标是什么？
\我们的目标是找出象工作流引擎、业务流程管理、消息解决方案，甚至是事务管理器这样的传统中间件服务在RESTful架构和应用中适合的位置。我们将通过定义一系列规范和指导方针来完成这项工作，这些规范和方针定义了这些服务的接口。有一件事我们不会做，那就是定义REST的含义或通用的RESTful指导方针。这最好留给REST社区的聪明人去完成。我们将关注于企业中间件，因为那是我们的专业领域。
\InfoQ: REST社区中有些人认为，完成企业分布式计算所需的全部材料在REST和HTTP中都已经存在了。那我们为什么还需要REST-*？
\大多数对REST的描述都会伴随使用人类Web（Human Web）来作为例子。对于“人类Web”，我认为是浏览器和使用这些浏览器的人。在我看来，基于机器的客户端如何与一个REST架构交互，还远未成熟。企业IT过去习惯使用特定的中间件技术去实现它们的分布式应用。REST的到来让我们有机会反思传统企业IT开发是如何与中间件交叉的。这正是REST-*.org试图解决的问题。我最终发现REST是中间件的死亡原因，但我猜想答案就位于其中的某个位置。
\InfoQ: 您如何看待REST-*未来的发展？
\我们首先会着手定义一系列我们想要为之创建RESTful接口的服务，以及每个这些服务将要解决的特定问题。从这一努力中，我们还希望得到一系列横跨我们正在特别定义的领域（如安全）的通用指导方针。当我们觉得我们获得的实质成果足以发表，我们将会把我们的工作带到象IETF 或W3C这样的标准团体。
\InfoQ: 参与的流程是怎样的？比方说，它对个人是开放的吗？还是仅仅只针对厂商？
\REST-*.org是一系列的开源项目，其目标是定义规范和指导方针。我们发布的所有东西都将是开源许可的。我们目前已经选择了ASL 2.0，但也有可能将该许可证变更到其他许可证。
\既然我们将REST-*.org作为开源项目运营，我们要做的每一件事也将是以开放方式完成。任何个人和组织都可以参与。他们要做的全部事情就是订阅我们的邮件列表。我们还希望外部公司或个人能推动部分我们的规范努力。尽管Red Hat是这个努力的发起者，但我们认为我们并不适合就是这些努力的主要推动者。
\InfoQ: REST和REST-*在JBOSS中的未来怎样？
\我们已经发现，随着我们的产品沿时间演变，使用传统的方法去定义我们的分布式管理和工具接口会变得太脆弱和难于管理。许多工程师都在寻找一种更好的方法。我认为REST可以解决部分这些问题。我们已经看到了一些将REST应用于我们某些产品的管理接口的好处。我希望它也将对配置和供应我们的项目和产品的方式有正面影响。
\至于REST-*，我们将在RESTEasy开源项目之下构建我们规范的初始实现。通过将我们的想法付诸实现，这将给我们提供一个有价值的反馈环。
\InfoQ: 您最后还有什么话想说？
\多年以来，分布式计算似乎是相同旧思想、模式和技术的不断重新打包。通过REST，我最终感觉分布式计算的再次演变和发展。尽管REST无法解决世界饥荒，但它肯定将给我们带来实践软件工程的新观点。
\
扫一扫
1498
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
