问题标签 [wadl]

我目前正在研究为 RESTfull 应用程序创建客户端 API 的选项。到目前为止，我们已经拥有 WCF 服务来允许所有应用程序连接到业务层，并且我们对它越来越不满意。

我们已经为 Web 准备了大部分基础设施（html 和 json 请求），但我们需要从其他应用程序访问服务（一些将与主要的 Web 应用程序模型库链接，而另一些则不会）。

我一直在这里和这里阅读有关 WADL 的信息，这似乎是有益的。我们可以生成 wadl、客户端库并使用它来检查 javascript url。

我想知道其他人使用了什么，什么有效，什么无效。

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

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

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

我读过一个很好的 WADL 文件示例。我还检查了WADL2Java工具。

但我似乎找不到 WADL 格式的完整规范。我有许多悬而未决的问题，主要是处理文件的各个部分如何相互关联，以及我是否可以通过使用引用来减少重复。

之后

leppie得到了官方的回答，但是那个文件有点糟糕。谁有更好的参考？

有没有办法在 Ruby on Rails 中发布 RESTful 方法所期望的参数？使用 SOAP，我们可以使用 WSDL，但是 RoR 是否为 RESTful 服务实现了 WADL 或 WSDL 2.0？编辑：我知道使用 ActionWebService 的基于 SOAP 的解决方案。我指的是与https://wadl.dev.java.net/等效的 RoR

我正在寻找一种代码生成器，它可以生成 C# 代码来访问由WADL 文件描述的 RESTful Web 服务，其方式类似于wadl2java的工作方式。

在进行 som 搜索时，我发现了 Google Code 上的rest-api-code-gen项目，但尽管最新的源代码确实支持 C#，但REST Describe & Compile 演示站点不支持。（C# 按钮在那里，但它被禁用了。）

我意识到我可以下载源代码并使用最新版本设置自己的服务器，但我不希望这样做，因为我需要的是命令行工具，而不是依赖于 Google Web Toolkit 的 Web 应用程序。我想我可以根据相同的源代码编写自己的命令行工具，但如果它已经完成，或者其他工具可以完成这项工作，我宁愿避免它。

所以，我想知道，那里有这样的工具吗？

为了描述 RESTful，我们可以说每个资源都有自己的 URI。使用 HTTP GET、POST、PUT 和 DELETE，我们可以对这些资源进行操作。所有资源都具有代表性。任何想要使用我们资源的人都可以通过浏览器或 REST 客户端进行操作。

这就是 RESTful 架构的主要思想。这种架构允许互联网上的服务。那么为什么这个架构需要WADL呢？WADL 提供了标准 HTTP 不提供的什么？为什么需要存在 WADL？

我看到的大多数 REST 接口都是用一个简单的网页描述的，描述了 URL、方法、接受的输入和返回的结果。例如Amazon S3或Twitter API文档。

对于亚马逊或 Twitter 来说，人类可读性显然已经足够了。但是，是否有任何公司以机器可读的格式描述 REST API？如果是，是哪些？

WSDL 2.0 声明能够描述 REST。WADL是为描述 REST 服务而显式创建的。WSDL 2.0 和 WADL 似乎都有一个相当小的后续 atm，并且对于创建和维护描述文档的努力似乎没有什么回报。通过识别现实生活中的例子，基本上可以验证或否定这个假设。

您是否使用 WSDL/WADL 来描述您的服务？你是否依赖 WSDL/WADL 来消费别人的服务？您选择的工具目前是否支持其中任何一种？是否有任何可以使用的广泛使用的 REST 服务示例，并以机器可读格式详细说明？

• WSDL 2.0：www.w3.org/TR/wsdl20/
• WADL www.w3.org/Submission/wadl/
• XRD www.oasis-open.org/committees/download.php/35274/xrd-1.0-wd10.html

这三个都可以使用 REST API 描述符。有什么区别？我知道这是一个激烈的问题，但我只是想要一个比较，而不是一场激烈的战争：P

我有一个模棱两可的 REST api，类似于（这不是具体问题，只是给出了模棱两可的概念）：

我们一直在侥幸成功，因为我们的 .htaccess 文件在通用 ${product_name} 版本之前列出了更具体的“命令”形式，并且第一场比赛获胜。但是，现在我们正在编写一个 WADL，并且正如您所料，我们在使用 WADL 时选择的工具遇到了麻烦，因为 API 是模棱两可的。我的问题是：

a) WADL 规范是否说明它们是否可以有效地表示模棱两可的 API？

b) 工具支持 - 根据您的经验，工具是否会因模棱两可的 WADL 而窒息？（如果允许 ambi. WADL，那么这些是弱工具，但是，您希望安全起见）

c) 任何关于模糊 REST api 的经验，尤其是 wrt WADL，真的。

对于好奇，这是最新的规范：

据我所知，它并没有专门解决这个问题，我想这真的取决于工具如何处理它。

查看当前版本的 WADL 提案，我不太清楚如何记录 POST 请求参数（带有application/x-www-form-urlencoded编码）。

我在野外见过这样的事情：

但是，对于<param style="query">用作 的子级的 a <request>，规范将其描述为：

指定根据 queryType 属性指定的查询组件媒体类型的规则表示的URI 查询参数。

“URI 查询”位让我大吃一惊，因为对我来说，它建议将参数附加到 URI 而不是包含在正文中。

另一方面，对于<param style="query">用作 的子级的 a <representation>，规范具有：

将表示的组件指定为根据媒体类型规则格式化的名称值对。通常与媒体类型“application/x-www-form-urlencoded”或“multipart/form-data”一起使用。

我是否必须使用一个<representation>元素来明确记录将作为 POST 正文的一部分以编码形式发送的参数？

这看起来有点矫枉过正。我假设我应该能够使用前者，即使规范提到了“URI 查询”。