rest - 为什么 WADL 吸收缓慢？

Question

我一直在研究 WADL，我想知道为什么它没有被更广泛地采用？

随着 REST 使用率的增长，我很惊讶更多的开发工作没有使用它。

它的设计是否存在根本性缺陷，它与通常围绕 RESTful Web 服务的文化不匹配，还是完全不同？

Answer 1

我认为 WADL 没有得到普及的主要原因是它可能使我们在使用 SOAP 和 WSDL 时遇到的所有问题重新焕发生机。对我来说，互操作性方面是 Web 服务最重要的方面。
通过遵循使用纯 HTTP 标准的 RESTful 方式，您可以“免费”获得互操作性。一旦你需要一个文档来描述服务，就会有不同的客户端框架（或不同的服务器框架）以不同的方式解释这个文档。一旦不同的框架从 WADL 自动生成代码，您将不得不再次处理互操作性问题。

缺乏标准是 RESTful 方式的弱点和优势，让我们给简单的方式一个机会。（尽管我们真的很喜欢自动代码生成:-)）

Answer 2

Jim Webber、Savas Parastatidis 和 Ian Robinson 的“实践中的 REST：超媒体和系统架构”提到了四个问题：

1. WADL 预先获取 Web 应用程序的静态视图，其中 Web 使用媒体类型和合同链接
2. WADL 工具促进了客户端和服务端抽象的紧密耦合。从服务通告的资源成为客户端的域模型。
3. WADL 没有提供有关与它所宣传的资源的交互顺序的任何线索。
4. WADL 通常会复制资源中可用的元数据。

第 1 点和第 2 点是关于动态与静态客户端绑定的参数。使用 WADL 时，服务实现者需要注意模式的向后兼容性，因为服务会发生变化。如果没有 WADL，客户端必须灵活地解释响应。

第 3 点涉及工作流程。WADL 没有记录调用 API 的顺序。如果服务是根据HATEOAS实施的，那么 WADL 和非 WADL 服务响应都提供了通过链接进行排序的线索。

第 4 点假定 HEAD 和 OPTIONS 结果可能与 WADL 定义不一致。在实践中，很少实施或使用这些方法中的任何一种。

许多 REST 实现既快速又肮脏。实现一个只供我使用的 REST 服务很容易。当我必须为不同团队提供的服务创建客户端时，我需要文档。越正式越好。代码可读的文档，例如 WADL，将是最好的。

作为客户实施者，我的担忧是：

1. 如何发现支持的查询参数和标头？
2. 如何找到有关请求或响应媒体类型的文档？即使它是 IANA 注册的媒体类型，我仍然需要请求/响应模式。