如何发现 RESTful Web 服务？
当我想找到所需功能的“大”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 服务吗？
When I want to find a "Big" Web service (WS-*/WSDL based) of required functionality I can simply google for ".... filetype:wsdl" because Google indexes also WSDL definitions. Or I can simply use some registries that already crawled the Web for WSDL definitions for me, e.g. SeekDa.com or ServiceFinder.
When I want to find RESTful Web service (RESTful Web API) I may count only on the community, because it is not possible to distinguish between URI of RESTful Web service and other Web resources (e.g. Web sites URLs) and hence any focused crawler cannot tell for 100% sure: this is URI of RESTful Web service. So, I come e.g. to the ProgrammableWeb.com and I hope someone already used/found the service I'm looking for and registered it there.
Recently, I was looking for the Web service for abbreviation expansion. I couldn't find it in portals like ProgrammableWeb, because no-one has put it there. Finally I was forced to browse through several abbreviation dictionaries sites, dig and drill there and I finally found Abbreviations.com Web service API in RESTful form. That took me a lot of time!
Is there any other Way to discover RESTful Web services on the Web?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您公开了一个约定（例如 REST API 设计手册中推荐的约定）服务根目录下的 /api 端点。这将返回一个 XML 或 JSON 响应，其中包含您的服务支持的“子”资源，例如 /api/products
There is a convention (recommended in REST API Design Handbook for example) that you expose a /api endpoint at the root of your service. This returns an XML or JSON response containing the "child" resources that your service supports e.g. /api/products
REST 的理想是服务与网页一样可使用，它们不需要注册表。 [必须承认，我没有完全“理解”这个 RESTful 世界的含义，没有 WSDL，没有注册表，感觉就像骑着没有稳定器的自行车。]
在 Google 出现之前的旧 Web 中，我们如何找到页面？有效的口碑传播和几个关键出发点。据我所知，REST 服务几乎还处于 Google 出现之前的阶段。
我不同意“不可能区分 RESTful Web 服务的 URI 和其他 Web 资源”——如果我们点击链接，我们会得到某些类型的内容 application/xml 和 application/json 将是非常强大的指标他们吗？
The REST ideal is that services are as consumable as Web Pages are, they don't need registries. [Got to admit I don't fully "get" the implications of this RESTful world, no WSDL, no registry feels like riding a bike with no stabilisers.]
In the old Web, pre-Google, how did we find pages? Effectively word-of-mouth and a few key starting points. REST services so far as I can see are pretty much in the pre-Google stage.
I don't agree that "it is not possible to distinguish between URI of RESTful Web service and other Web resources" - if we follow the link we get certain types of content application/xml and application/json would be pretty strong indicators wouldn't they?
REST Web 服务有一个类似 WSDL 的文件：它称为 WADL。
There's a WSDL-like file for REST webservices: it's called WADL.
SoapUI 现在可以发现 REST 服务。它作为代理工作，记录通过的所有请求/响应。有了请求和响应，SoapUI 就会重新创建服务的描述/定义。
现在，定义可以以 WADL 和 WSDL 格式存储（如 XML 世界中的 WSDL 和 XML-Schema）。它还可以以 Swagger 格式存储。我更喜欢斯瓦格。
Swagger 可以直接从 SoapUI 存储在 SwaggerHub 中，这就像源代码的 GitHub。 SwaggerHub 是众多 API 管理系统之一。
SoapUI now can discover the REST services. It works as a proxy, writing down all requests/responses that pass through. Having requests and responses SoapUI recreates descriptions/definitions of the services.
Now the definitions can be stored in WADL and WSDL formats (as WSDL and XML-Schema in XML world). It also can be stored in Swagger format. I prefer Swagger.
Swagger can be stored in SwaggerHub right from SoapUI, which is like GitHub for source code. SwaggerHub is one of many API management systems.