问使用WADL的原因是什么？

EN

WADL的目的是定义一个合同。合同规定了一方如何呼叫另一方。

当您从头开始创建web应用程序时，您不需要contract和WADL。

当您将您的系统与其他系统集成在一起，并且您可以与他们的开发团队进行清晰的沟通时，您不需要contract和WADL (因为您可以通过电话将事情说清楚)。

但是，当您将一个复杂的企业系统与由几个不同的公司(或联邦机构)维护的其他几个复杂的企业系统集成在一起时，请相信我您希望尽可能严格地定义通信契约。WADL，然后你需要或开放规范。非常需要它，。

企业背景较弱的人倾向于将整个IT视为独立开发的独立web应用程序的集合。但企业的现实有时是艰难的。有时，您甚至不能给开发您必须与之集成的应用程序的人员打电话或写信。有时，您与不再维护的遗留应用程序通信--它只是运行，您需要弄清楚如何正确地与它通信。在这种情况下，你需要一份合同，因为它可以节省你的。

实际上，客户端生成是契约定义的次要功能。这只是个玩具。契约强制不好的通信者清楚地传达集成规则。这是使用WADL或Open Specification或其他语言的主要原因。

使用WADL意味着您可能已经足够亲切地定义了来回传递的数据/文档。假设您正在传递一些XML片段，它们实际上可能是已定义模式的一部分。

你是否使用DL生成代码对我来说并不是很重要。在我的主观观点中，重要的是在业务伙伴之间的接口上有一个正式的协议是很重要的。即使传递的内容是显而易见的，它也有助于确定如果有人更改了以前的接口，谁必须在以后修复哪些内容。

数据格式和动词名称一样是接口的一部分。

WADL对来自SOAP世界的人们很有吸引力，因为在SOAP世界中，通常使用代码生成器来创建基于WSDL的客户端代码。我不认为这种机制在REST中有用，因为它创建了耦合到服务器端点的客户端代码。

我相信，如果您正确地定义了您的媒体类型并在这些媒体类型中使用了超媒体，那么就没有必要使用WADL。可用端点的描述包含在媒体类型定义本身中。如果您现在对自己说，但application/xml不包含任何有关可用超链接的信息，那么我会说BINGO。这就是为什么我不认为application/xml和application/json是适合REST的媒体类型的原因。我并不是说不要使用XML或JSON，只是不要使用通用的媒体类型名称。

WADL的另一个吸引力在于记录REST服务。不幸的是，当WADL试图记录服务器端端点时，它会将开发人员引向错误的道路。记录REST服务应该主要关注媒体类型。客户端开发人员应该能够编写REST客户端，而不需要知道根url以外的任何url。