在今年的 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?
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论