为什么缓慢的WADL吸收？

Question

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

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

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

Answer 1

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

缺乏标准是RESTful方式的弱点和强度，让我们给出一个简单的方法。 （即使我们真的很喜欢自动代码生成:-)）

Answer 2

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

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

积分1＆amp; 2是关于动态与静态客户端绑定的参数。使用WADL时，服务实现者在服务更改时需要注意模式的向后兼容性。如果没有WADL，客户端必须灵活地解释响应。

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

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

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

我作为客户端实现者的担忧是：

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