当我想找到所需功能的“大”Web 服务（基于 WS-*/WSDL）时，我可以简单地在 google 中搜索“.... filetype:wsdl”，因为 Google 也会对 WSDL 定义进行索引。或者我可以简单地使用一些已经在 Web 上抓取 WSDL 定义的注册表，例如SeekDa.com 或 ServiceFinder。
当我想找到 RESTful Web 服务（RESTful Web API）时，我可能只能依靠社区，因为无法区分 RESTful Web 服务的 URI 和其他 Web 资源（例如网站 URL），因此无法区分任何专注的爬虫无法 100% 确定：这是 RESTful Web 服务的 URI。所以，我来了，例如到 ProgrammableWeb.com，我希望有人已经使用/找到了我正在寻找的服务并在那里注册了它。
最近，我在寻找缩写扩展的Web服务。我在 ProgrammableWeb 之类的门户网站上找不到它，因为没有人把它放在那里。最后我被迫浏览了几个缩写词典网站，在那里挖掘和钻取，我终于找到了 RESTful 形式的 Abbreviations.com Web 服务 API。这花了我很多时间！
还有其他方法可以在 Web 上发现 RESTful Web 服务吗？
有一个约定（例如，在REST API 设计手册中推荐），即在服务的根目录公开 /api 端点。这将返回一个 XML 或 JSON 响应，其中包含您的服务支持的“子”资源，例如/api/产品
REST 的理想是服务与网页一样可消费，它们不需要注册表。 [必须承认我没有完全“理解”这个 RESTful 世界的含义，没有 WSDL，没有注册表感觉就像骑着没有稳定器的自行车。]
在谷歌出现之前的旧网络中，我们如何找到页面？有效的口碑传播和几个关键出发点。据我所知，REST 服务几乎还处于 Google 之前的阶段。
我不同意“不可能区分 RESTful Web 服务的 URI 和其他 Web 资源”——如果我们点击链接，我们会得到某些类型的内容 application/xml 和 application/json 将是非常有力的指标不是吗？
有一个用于 REST Web 服务的类似 WSDL 的文件：它称为 WADL。
SoapUI 现在可以发现 REST 服务。它作为代理工作，记录通过的所有请求/响应。有了请求和响应，SoapUI 就会重新创建服务的描述/定义。 现在，定义可以以 WADL 和 WSDL 格式存储（如 XML 世界中的 WSDL 和 XML-Schema）。它还可以以 Swagger 格式存储。我更喜欢斯瓦格。 Swagger 可以直接从 SoapUI 存储在 SwaggerHub 中，这就像源代码的 GitHub。 SwaggerHub 是众多 API 管理系统之一。