我们有一个使用URL http://example.com托管的Web应用程序。现在，我们希望将该应用程序的一部分扩展为一种静态服务，并且我们正在讨论最佳URL模式。我进行了搜索，但找不到任何具体指导。
我们应该使用网址格式http://api.example.com还是http://example.com/api/v1？
对此有任何标准指导吗？
取决于您的需求。
如果使用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
最后但并非最不重要的一点，PayPal使用模式http://example.com/api/v1。
我认为您不应该考虑不使用http://api.example.com或http://example.com/api/v1。
相反，我建议使用http://example.com/api和内容协商进行版本控制。
我的想法为何：
使用子域：
根据URI Scheme Specification，您正在URI的权限部分中定义API，该API用于定义主机，而不是在主机上定义应用程序或API。您实际上是在为API创建一个不同的地址，这意味着api.example.com的身份验证可能不起作用，例如example.com。
这样做的有效理由可能是在为移动设备设计新实例时，例如mobile.example.com，但我认为这更多是一项基础架构决策，而不是功能性决策。
在主域上使用未版本控制的路径：
这里有两点信息：一个指示存在API资源，第二个指示存在该API资源的版本号（v1）。
使用/api/在API和可能在/web/下运行的Web视图之间进行区分没有什么不好。这可以被认为是常见的最佳实践。
我不确定您是否打算这样做，但是您的问题包括有关如何解决API版本控制的查询。就我个人而言，我认为不应使用URL来进行API版本控制，因为它们旨在尽可能长时间地保持稳定。 Cool URIs don't change!相反，请考虑使用HTTP内容类型信息来对API进行版本控制。我实际上发现此方法在VMware documentation中使用。此外，这是一个相当古老但仍然有用的关于Peter Williams的内容类型版本化的文章。
这是一个折衷的情况，没有一个最佳的解决方案。
例如，如果您的http://example.com/通过标准的Web界面以及API提供内容，则您需要类似http://api.example.com/api/<version>/<the usual resource pattern>的内容只是为了将基于浏览器的应用程序访问与API交互分开。这有意义吗？
示例：api.rottentomatoes.com
但是，即使您的域专用于API调用，还是要使用上述模式，并为与应用程序进行交互的其他方式保留http://example.com/，这很有意义。例如，您可能需要http://example.com/mobile/等