为什么慢WADL摄取？

Question

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

随着REST使用率的增长速度，我感到惊讶的是，更多的开发工作不使用它。

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

Answer 1

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

缺乏标准是RESTful方式的弱点和优势，让我们给出简单的方法一个机会。 （即使我们真的很享受自动代码生成:-)）

Answer 2

“REST实践：超媒体系统的体系结构”由吉姆·韦伯，萨瓦斯Parastatidis，和伊恩·罗宾逊提到4个担忧：

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注册的媒体类型，我仍然需要请求/响应模式。