什么是使用WADL的原因？
为了描述RESTful，我们可以说每个资源都有自己的URI。 使用HTTP GET，POST，PUT和DELETE，我们可以对这些资源进行操作。 所有资源都是代表性的。 谁想要使用我们的资源可以通过浏览器或REST客户端来完成。
这是RESTful架构的主要思想。 这种架构允许在互联网上的服务。 那么为什么这个架构需要WADL呢？ WADL提供的标准HTTP不是什么？ 为什么WADL需要存在？
WADL的目的是定义合同 。 合同规定了一方如何打电话给另一方。
从头开始创buildWeb应用程序时， 不需要合同和WADL 。
当你将系统与其他系统集成在一起，并且你可以和他们的开发团队进行清晰的沟通时， 你不需要合同和WADL （因为你可以打个电话来说清楚）。
然而，当你将一个复杂的企业系统与其他几个不同的公司（或联邦机构）维护的复杂的企业系统整合在一起时，请相信我， 你希望有一个尽可能严格的通信合同。 那么你需要WADL或Open Specification。 需要严重 。
企业背景薄弱的人倾向于将整个IT视为独立开发的独立Web应用程序集合。 但企业的现实有时是艰难的。 有时甚至无法打电话或写信给开发您必须与之集成的应用程序的人员。 有时候，您会与不再维护的遗留应用程序进行通信 – 它只是运行，您需要弄清楚如何正确地与之通信。 在这种情况下，你需要一份合同，因为它能节省你的屁股
实际上客户生成是合同定义的次要特征。 这只是一个玩具。 合同强制不良沟通者清楚地沟通整合规则。 这是使用WADL或Open Specification或其他的主要原因。
使用WADL意味着你可能会很有礼貌地实际定义你传递的数据/文档。 假设你传递了一些XML片段，它们实际上可能是定义模式的一部分。
是否使用DL生成代码对我来说并不重要。 根据我的主观看法，重要的是对业务合作伙伴之间的界面达成正式的协议。 即使通过的内容是显而易见的，它有助于确定稍后如果有人更改以前的界面，谁来修复。
数据格式与动词名称一样是界面的一部分。
WADL呼吁来自SOAP世界的人们，通常使用代码生成器来创build基于WSDL的客户端代码。 我不认为这种机制在REST中是有用的，因为它创build了耦合到服务器端点的客户端代码。
我相信，如果你正确地定义你的媒体types，并在这些媒体types中使用超媒体，那么就没有必要拥有WADL。 可用端点的描述包含在媒体types定义中。 如果你现在正在对自己说，但是application / xml不包含有关可用超链接的任何信息，那么我说BINGO。 这就是为什么我不认为application / xml和application / json是适合REST的媒体types的原因。 我不是说不使用XML或JSON，只是不使用通用的媒体types名称。
WADL的另一个吸引力是为了loggingREST服务。 不幸的是，WADL试图logging服务器端的端点，导致开发人员走错了路。 loggingREST服务应主要关注媒体types。 客户端开发人员应该能够编写一个REST客户端，而不需要知道除根URL之外的任何url。
WADL允许您生成代码，testing和文档。 实际上使用WADL的工具很less，你可以在这里看到一些例子。 正如菲尔丁的论文所描述的那样，“纯粹的”REST的问题在于编写支持超媒体的客户端（想象一下，例如，编写基于Java Swing的客户端应用程序）。 使用WADL这个任务是完全自动化的，在我看来这是一个巨大的优势。 testing也变得更容易。
在我给出我的解释之前，让我说，大多数纯粹的REST极端主义者会嘲笑它到地球的尽头。 我不同意他们，因为我宁愿把事情做完，但只要你知道。
WADL是一个Web服务API的描述，有点像WSDL用于SOAPtypes的Web服务，它被devise成更适合于RESTful接口（WSDL很糟糕）。
根据我的经验，主要用法是允许您生成可以调用服务的客户端代码（如果它是一个非常大的API，则可以方便地节省工作时间）。 它也用于logging类似REST的界面。
REST对WADL没有任何规定。
当你想公开REST服务时，最好的方法是生成WADL并与消费者共享（类似于基于SOAP的Web服务中的WSDL）.WADL用于描述服务的全部内容。
