是时候将WADL加入到JAX-RS中了吗？

在今年的JavaOne上，有一个名为'JavaEE.Next(): Java EE 7, 8, and Beyond' 的专题，包括Oracle、IBM、Red Hat以及Caucho所组成的小组讨论了Java EE的各个方面，并回答了观众的问题。最初预想的焦点会是Paas、移动开发以及NoSQL，但是与会者对REST尤其是WADL也表现出了极大的兴趣。现在，WADL并不是新鲜事物，它已经存在并被广泛讨论了至少七年的时间，我们在2005年曾经这样报道过：

对于那些想在HTTP服务上描述XML的人来说， 已经讨论过很多可选的方案了，从 SMEX-D （Tim Bray所提出的）到 NSDL，以及其他众多的可选方案。但是，大多数提议都是在2005年甚至更早的时候创建的，从那以后它们都没有较大的改进。

Marc Hadley（ JSR-311规范的负责人之一，这个规范是RESTful服务的一种Java API）在2005年 提出了  WADL——Web应用描述语言。

从那以后，很多人构建工具来支持WADL。Yahoo的架构师  Mark Nottingham维护了 能够从WADL生成文档的一个样式表。

就像围绕REST的某些事情一样，在过去，WADL将社区分裂成相信WADL必要和非必要的两派。例如，在2007年Mark Baker曾经这样说：

[...] 所有服务暴露相同的接口。这就提供了大多数的 松耦合，这也是与RPC的 主要区别。 

所以如果你正在编写（或生成）协议/接口级别的代码，而这些代码不能延迟绑定到所有地方的所有资源上，这样做其实不是REST（对指出这违反了特定约束的人，应该给予莫大的荣光）。

我们已经挣脱了约束！RPC已死！你不能再为所欲为了！

而喜欢它的人通常将其与WSDL进行比较：

回忆一下WSDL，它能够很简单地 生成到web服务的交互代码。这一点很棒，可以节省大量的工作。在RESTful web服务中，我们同样可以这么做吗？是的，可以的。最终，我的结论就是，你可以借助 WADL做到这一点。WADL代表了Web应用描述语言，它能够为任意的web服务（包括SOAP web服务，这可能让你感觉意外）描述基于HTTP的API。但是你还可以用WADL描述flickr API、twitter API以及yahoo API。猜一下它能做什么… 它能够生成客户端代理代码来与这些API交互。是的，它与WSDL很类似，但是更通用。它能够统一支持REST和其他任意（我猜）类型基于XML的web服务。

但正如一位评论者所言，它可能是双刃剑：

在这篇文章中犯了几个根本性的错误。你说"我在这里所叙述的是，结果的格式和发送给REST web服务的数据都是精确定义的XML。那么，当我要求媒体类型的时候会怎样？他们也是精确定义的数据格式，它们与怎样处理数据以及如何基于表述获取新的资源相关。

读一读Roy Fielding的作品吧; )

顺便说一句，WADL可能并不会长久，它实际上一点都不RESTful（在客户端和服务提供者之间建立了紧耦合）。

在2005到2008的几年间，类似这样的争论在REST领域泛滥。最近，争论似乎逐渐平息，出现了更务实的前景。有些组织觉得，尽管WADL还有一些问题（如它是否RESTful），但对于开发者而言，它应该是一个要支持的方案。而另外一些组织则完全避开了它。例如JAX-RS的参考实现Jersey就内置支持了WADL。而另一些 JAX-RS 实现，如RESTeasy，就没有这样明确支持。

让我们回到JavaOne这个专题上来，很多观众包括JAX-RS规范的负责人，都很想知道未来版本的JAX-RS是否要完全支持WADL。然而讨论小组未置可否，并提及很多成功的RESTful服务并没有使用WADL，但是很多观众倾向于支持将WADL加入到JAX-RS中。鉴于最近几年WADL的影响力处于低潮期，这会不会是Java和JAX-RS的特殊需求，WADL会不会再次得到关注呢？如果是这样的话，WADL会不会使得现在开发的RESTful服务和应用程序比几年前的更好呢？会不会使得今天的开发人员比以前更务实呢？

查看英文原文： Is It Time For WADL in JAX-RS?