java 将 REST API 放在子域还是子文件夹中更好？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/14554943/
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 it better to place a REST API on a subdomain or in a subfolder?
提问by Abhijith Prabhakar
We have a web application which is hosted with the URL http://example.com. Now we want to extend a part of this application as a restful service, and we are debating on the best URL pattern. I searched, but could not find any concrete guidance.
我们有一个使用 URL 托管的 Web 应用程序http://example.com。现在我们想将这个应用程序的一部分扩展为一个安静的服务，我们正在讨论最佳的 URL 模式。我搜索过，但找不到任何具体的指导。
Should we have the URL pattern http://api.example.comor http://example.com/api/v1?
我们应该使用 URL 模式http://api.example.com还是http://example.com/api/v1?
Is there any standard guidance for this?
是否有任何标准指导？
回答by Jobert Enamno
It depends on your needs.
这取决于您的需求。
If you use http://api.example.comit makes your API a subdomain. Basically, this URL pattern is good if your REST service is to be consumed by multiple clients, but if only one client is connected to your API then the pattern http://example.com/api/v1is good. However, if you want to add more API with more clients connected to it it’s better to use http://example.com/api/v1. For example, consider the following.
如果您使用http://api.example.com，它会使您的 API 成为子域。基本上，如果您的 REST 服务要被多个客户端使用，则此 URL 模式很好，但如果只有一个客户端连接到您的 API，则模式http://example.com/api/v1很好。但是，如果您想添加更多 API 并连接更多客户端，最好使用http://example.com/api/v1。例如，请考虑以下情况。
http://example.com/reportapi/apioperation?parameters
http://example.com/paymentapi/apioperation?parameters
http://example.com/searchapi/apioperation?parameters
Last but not least, PayPal uses the pattern http://example.com/api/v1.
最后但并非最不重要的一点是，PayPal 使用模式http://example.com/api/v1。
回答by brazo
I think you should consider using neither http://api.example.comnor http://example.com/api/v1.
我认为您应该考虑既不使用http://api.example.com也不使用http://example.com/api/v1.
Instead I would suggest using http://example.com/apiand content negotiation for versioning.
相反，我建议使用http://example.com/api和内容协商进行版本控制。
Here are my thoughts why:
以下是我的想法：
Using a subdomain:
使用子域：
Per the URI Scheme Specification, you are defining the API in the authority part of the URI, which is used to define your host, rather than defining an application or API on your host. You are actually creating a different address for your API, which means that authentication might not work for api.example.com as it does for example.com.
根据URI 方案规范，您在URI的授权部分定义 API，用于定义您的主机，而不是在您的主机上定义应用程序或 API。您实际上是在为您的 API 创建一个不同的地址，这意味着身份验证可能不适用于 api.example.com，因为它适用于 example.com。
A valid reason to do this might be when designing an new instance for mobile devices, e.g. mobile.example.com, but I would consider this more an infrastructural decision and not a functional one.
这样做的一个正当理由可能是在为移动设备设计新实例时，例如 mobile.example.com，但我认为这更像是一种基础设施决策，而不是功能决策。
Using an unversioned path on the main domain:
在主域上使用未版本化的路径：
There are two bits of information here: one is an indication that there is an API resource and the second is that there the version number of that API resource (v1).
这里有两个信息：一个是指示存在 API 资源，第二个是该 API 资源 (v1) 的版本号。
There is nothing bad about using /api/to put a distinction between the API and, for example, your web view that might run under /web/. This can be considered common best practice.
使用/api/区分 API 和例如可能在/web/. 这可以被认为是常见的最佳实践。
I am not sure whether you intended this, but your question includes a query on how to solve API versioning. Personally, I think that API versioning should not be done using URLs, as they are intended to stay stable for as long as possible. Cool URIs don't change!Instead, consider using HTTP Content-Type information to version your API. I actually found this method used in VMware documentation. Additionally here is a quite old, but still useful, post about content type versioning by Peter Williams.
我不确定您是否打算这样做，但您的问题包括有关如何解决 API 版本控制的查询。就我个人而言，我认为不应该使用 URL 来完成 API 版本控制，因为它们旨在尽可能长时间地保持稳定。酷 URI 不会改变！相反，请考虑使用 HTTP 内容类型信息来版本您的 API。我实际上在VMware 文档中发现了这种方法。此外，这是一篇由Peter Williams撰写的关于内容类型版本控制的相当古老但仍然有用的帖子。
回答by TheWhiteRabbit
This is a case of tradeoffs, with no single best solution.
这是一种权衡的情况，没有单一的最佳解决方案。
For example, if your http://example.com/provides content through a standard web interface as well as through the API, then you need something like http://api.example.com/api/<version>/<the usual resource pattern>just to separate browser-based application access from API interaction. Does this make sense?
例如，如果您的http://example.com/通过标准 Web 界面和 API 提供内容，那么您需要http://api.example.com/api/<version>/<the usual resource pattern>将基于浏览器的应用程序访问与 API 交互分开。这有意义吗？
Example: api.rottentomatoes.com
示例：api.rottentomatoes.com
However, even if your domain is dedicated for API calls, it's meaningful to use the above pattern anyway, and reserve http://example.com/for other ways of interacting with your application. For example, you might want http://example.com/mobile/, etc.
但是，即使您的域专用于 API 调用，无论如何使用上述模式还是有意义的，并保留http://example.com/以用于与您的应用程序交互的其他方式。例如，您可能需要http://example.com/mobile/等。
