为了描述RESTful，我们可以说每个资源都有自己的URI。使用HTTP GET，POST，PUT和DELETE，我们可以对这些资源进行操作。所有资源均具有代表性。任何想要使用我们资源的人都可以通过浏览器或REST客户端来使用。
这是RESTful架构的主要思想。这种体系结构允许Internet上的服务。那么为什么这种架构需要WADL？WADL提供了哪些标准HTTP不提供的东西？为什么WADL需要存在？
Answers:
WADL的目的是定义合同。合同规定了一方可以打电话给另一方的方式。
从头开始创建Web应用程序时，不需要合同和WADL。
当您将系统与另一个系统集成在一起并且可以与他们的开发团队进行清晰的沟通时，您不需要合同和WADL（因为您可以打个电话来使事情变得清晰）。
但是，当您将一个复杂的企业系统与由几个不同的公司（或联邦机构）维护的其他几个复杂的企业系统集成在一起时，请相信我，您希望尽可能严格地定义一个通信合同。然后，您需要WADL或开放规范。急需它。
具有弱企业背景的人们倾向于将整个IT视为独立开发的独立Web应用程序的集合。但是企业现实有时很难。有时，您甚至无法致电或写信给开发必须与之集成的应用程序的人员。有时，您与不再维护的旧应用程序通信-它仅在运行，您需要弄清楚如何与之正确通信。在这种情况下，您需要签订合同，因为它可以节省您的资金。
实际上，客户生成是合同定义的次要特征。只是个玩具而已。合同强制不良沟通者清楚地传达集成规则。这是使用WADL或Open Specification或其他任何方式的主要原因。
使用WADL意味着您可能足够优雅地实际定义了来回传递的数据/文档。假设您要传递一些XML片段，它们实际上可能是已定义模式的一部分。
对我来说，是否使用DL生成代码并不重要。在我的主观意见中，重要的是，就业务合作伙伴之间的接口达成正式协议很重要。即使通过的内容很明显，它也有助于确定如果有人更改了先前的界面，谁必须在以后修复问题。
数据格式与动词名称一样，也是界面的一部分。
WADL吸引了来自SOAP世界的人们，在SOAP世界中，通常使用代码生成器来基于WSDL创建客户端代码。我认为该机制在REST中没有用，因为它创建了与服务器端点耦合的客户端代码。
我相信，如果您正确定义了媒体类型并在这些媒体类型中使用了超媒体，那么就没有必要使用WADL。可用端点的描述包含在媒体类型定义本身中。如果您现在对自己说，但是application / xml不包含有关可用超链接的任何信息，那么我说宾果。这就是为什么我不认为application / xml和application / json是REST合适的媒体类型。我并不是说不要使用XML或JSON，只是不要使用通用媒体类型名称。
WADL的另一个吸引力是记录REST服务的目的。不幸的是，当WADL尝试记录服务器端端点时，它导致开发人员走错了路。记录REST服务应主要集中在媒体类型上。客户端开发人员应该能够编写REST客户端，而无需知道根URL以外的任何URL。
在我解释之前，我要说的是，大多数纯粹的REST极端主义者都会嘲笑它到地极。我不同意他们的意见，因为我宁愿做些事，但请注意。
WADL是对Web服务API的描述，有点像WSDL是针对SOAP类型的Web服务的，其设计目的是与RESTful接口更加协调（WSDL不擅长）。
根据我的经验，它的主要用法是允许您生成可以调用该服务的客户端代码（如果它是一个非常大的API，则非常方便，实际上可以节省工作时间）。它还可用于记录类似REST的接口。