Java 有没有办法发现 ReST API 的所有端点？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/28993724/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is there a way to discover all endpoints of a ReST API?
提问by 4m1r
I'm wondering if its possible to programmatically discover all the endpoints of a particular API.
我想知道是否有可能以编程方式发现特定 API 的所有端点。
So for example if I GET this URL with a browser or curl: https://api.twitter.com/1.1/
例如，如果我使用浏览器或 curl 获取此 URL：https: //api.twitter.com/1.1/
I might get something like this as a JSON response:
我可能会得到这样的 JSON 响应：
{"TwitterAPI":{
"version" : 1.1,
"GET" : {
"search/" : ["users", "trending"],
"users/" : ["id", "handle"]
}
}
Of course Twitter could choose to publish or not publish this format. So as a side question, are there any libraries for Java or Javascript that will automatically map and publish the API routes you created in your controllers?
当然，Twitter 可以选择发布或不发布这种格式。那么作为一个附带问题，是否有任何 Java 或 Javascript 库可以自动映射和发布您在控制器中创建的 API 路由？
采纳答案by Gergely Bacso
There is no way of programmatically discovering REST services as they do not have a standard registry service.
无法以编程方式发现 REST 服务，因为它们没有标准的注册服务。
Apart from doing something insane brute-force search there is no way of finding the right URLs ( not to mention the right parameters). So the only option is documenting your API. For that the best choice I have seen so far is:
除了做一些疯狂的蛮力搜索之外，没有办法找到正确的 URL（更不用说正确的参数了）。所以唯一的选择是记录你的 API。为此，我迄今为止看到的最佳选择是：
- Swagger
- And people also like API Blueprint.
- 昂首阔步
- 人们也喜欢API Blueprint。
回答by David
Some RESTful APIs publish a Web Application Description Language resource (WADL - pronounced like the walk that ducks do - for short). JAX-RS, or at least Jersy webapps will do this by default at the application root URL /application.wadl. It doesn't appear that Twitter's API is one of these. Many REST purists would argue that the API should be self describing and self discoverable simply by interacting with it and seeing what other endpoints it will give you.
一些 RESTful API 发布了一个 Web 应用程序描述语言资源（WADL - 发音像鸭子走路 - 简称）。JAX-RS 或至少 Jersy webapps 将默认在应用程序根 URL /application.wadl 执行此操作。Twitter 的 API 似乎不是其中之一。许多 REST 纯粹主义者会争辩说，API 应该是自我描述和自我发现的，只需与它交互并查看它会为您提供哪些其他端点。
回答by Qwerky
You should be able to discover everything you need to know about a REST API by only knowing the initial entry point. This is one of the fundamental points of REST; that it should be hypermedia driven and self describing. It is also one of the least understood principles. The discovery of resources is down to hypermedia links in the responses from the server.
您应该能够通过只知道初始入口点来发现您需要了解的有关 REST API 的所有信息。这是 REST 的基本要点之一；它应该是超媒体驱动和自我描述的。这也是最不为人知的原则之一。资源的发现取决于服务器响应中的超媒体链接。
Back as long ago as 2008 Roy Fielding started to get annoyed about people writing HTTP based APIs and calling them RESTjust because it was the hot new thing. Here are a couple of points he makes;
早在2008 年，Roy Fielding 就开始对人们编写基于 HTTP 的 API 并称它们为 REST 感到恼火，因为它是热门的新事物。以下是他提出的几点；
A REST API must not define fixed resource names or hierarchies(an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC's functional coupling].
REST API不得定义固定的资源名称或层次结构（客户端和服务器的明显耦合）。服务器必须能够自由控制自己的命名空间。相反，通过在媒体类型和链接关系中定义这些指令，允许服务器指示客户端如何构建适当的 URI，例如在 HTML 表单和 URI 模板中完成的操作。[这里的失败意味着客户端正在假设由于带外信息而导致的资源结构，例如特定于域的标准，这是面向数据的等效于 RPC 的功能耦合]。
and
和
A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience(i.e., expected to be understood by any client that might use the API). From that point on, all application state transitions must be driven by client selection of server-provided choices that are present in the received representations or implied by the user's manipulation of those representations. The transitions may be determined (or limited by) the client's knowledge of media types and resource communication mechanisms, both of which may be improved on-the-fly (e.g., code-on-demand). [Failure here implies that out-of-band information is driving interaction instead of hypertext.]
除了初始 URI（书签）和适用于预期受众的标准化媒体类型集（即，预期任何可能使用 API 的客户端都能理解）之外，REST API应该在没有任何先验知识的情况下输入。从那时起，所有应用程序状态转换都必须由客户端选择服务器提供的选项来驱动，这些选项存在于接收到的表示中或由用户对这些表示的操作暗示。可以通过客户端对媒体类型和资源通信机制的了解来确定（或限制）转换，这两者都可以即时改进（例如，按需代码）。[这里的失败意味着带外信息正在推动交互而不是超文本。]
What this means in practice is that the entry point (typically using the root URI of "/") contains links to other REST APIs. Those APIs will contain links to other APIs and so on. There should be no API that doesn't have a link to it. That would mean it is not discoverable.
这在实践中意味着入口点（通常使用“/”的根 URI）包含指向其他 REST API 的链接。这些 API 将包含指向其他 API 等的链接。应该没有没有链接的 API。这意味着它是不可发现的。
The other answers here fundamentally wrong in that they fail to acknowledge the most basic principle of REST.
这里的其他答案从根本上是错误的，因为他们没有承认 REST 的最基本原则。
