我刚刚阅读了Restful Web Services和Nobody Understands REST or HTTP，并尝试使用RESTful设计设计API。
我注意到API URI设计中的一些模式：
http://api.example.com/users
http://example.com/api/users
http://example.com/users
假设这些设计在XHTML，JSON或任何格式之间正确使用Accept和Content-type content negotiations标头。
这些URI是纯 RESTful实现与隐式内容协商的问题吗？
我的想法是，通过在URI中明确使用API，客户端将期望数据格式本质上不是令人愉悦的超媒体，并且可以在不明确设置Accept标头的情况下更容易地使用。换句话说，API暗示您期望JSON或XML而不是XHTML。
这是分离资源表示的问题 逻辑上在服务器端？
我能想出为什么有人会使用API子域设计URI的唯一理由是，基于我的假设这是一种扩展技术，它应该使多层服务器基础架构中的路由请求加载更容易。也许情况下反向代理正在剥离标题？我不知道。处理不同表示的不同服务器？
也许子域仅用于外部使用者，以便服务器避免内部使用的开销。限速？
我错过了一点吗？
我提议的设计会尝试通过设置适当的标头来跟踪RESTful实践，适当地使用HTTP谓词并以一种方式表示资源，我觉得在URI中包含'API'将是多余的。
为什么有人会在URI中使用'API'设计RESTful API？
或者他们可以吗？也许我不理解这个设计的问题是它无关紧要只要它遵循一些规范的组合，这可能不会导致RESTful API实现但是接近？ 为键盘猫设置皮肤的方法不止一种。 HATEOAS相关？
更新：在研究这个主题时，我得出结论，重要的是要考虑来自REST的想法，而不是将其视为宗教。因此，在URI中是否具有“api”更多的是设计决策而不是坚定的规则。如果您计划公开公开您的网站的API，最好使用api子域来帮助处理应用程序的逻辑。我希望有人能为他人贡献自己的见解。
答案 0 :(得分：11)
我会（而且已经）将它与“网站”基础设施分开，因为它可能会有更高的负载并需要更多的基础设施 - 每天进行数百万次API调用比在页面浏览量，因为您拥有n个网站/公司的全部负载以及他们的努力和牵引力，甚至在某些情况下，他们将会比您自己吸引更多的流量。
答案 1 :(得分：5)
还要记住，大多数框架（django，RoR，...）都提供了开箱即用的基于URL的路由。您可能需要针对API与HTML响应的不同视图来管理诸如身份验证，小跑，限制检查和其他特定内容之类的内容。
建立一个额外的基于HTTP-Header的路由系统，正如你所说的那样，允许隐式内容协商通常是不值得的。
答案 2 :(得分：5)
这是我对你的问题的理解和观点：
这些URI是否是纯RESTful实现与隐式实现的问题 内容谈判？
不，它们不属于任何官方文档（我知道），并且通常由开发人员/团队标准自行决定。例如，Zend Framework使用一些实用程序类来检测XHR请求以及如何返回响应。当然，ZF不是纯粹的RESTful设计（或者大多数PHP应用程序），但即使在PHP中也可以编写这样的设计。
我经常看到{ur}中使用的api当预期返回的数据确实无意用于显示给最终用户时。然而，这通常是一个设计决定，不一定是隐含的标准。
这是逻辑上分离资源表示的问题 服务器端？
或多或少。例如，当执行PUT请求时，接口不一定需要完全刷新，并且通常简单的响应消息就足够了。虽然此响应消息是视图的一部分，但它不是 视图。因此，例如，http://domay.com/users/将返回管理用户（或其他）的接口，http://domain.com/users/api将执行操作并返回接口更新（没有页面重新加载）。
我错过了一点吗？
Weell，没有。由于在URL中使用或不使用api是设计决定，因此您不会错过任何内容。使用正确的标题，
http://domain.com/users/api/get
http://domain.com/users/get
http://domain.com/users/
都可以是有效的RESTful请求。
为什么有人会在URI中使用'API'设计RESTful API？
简单地说，要有一个URL命名约定。因此，当查看日志，文档等中的请求时，人们会理解它的目的。
答案 3 :(得分：4)
用户可见的网页网址受网站管理员，设计师，企业组织，营销，时尚，技术等的影响。
另一方面，API应该保持稳定。通过使用子域，您可以将API与网站的其余部分隔离开来，以及它可能会及时发生的更改。