web-services - 为什么有人会设计一个 URI 中包含 'API' 的 RESTful API？

Question

我刚刚读完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

假设这些设计正确使用 content negotiations 的 Accept 和 Content-type header 。 XHTML、JSON 或任何格式之间。

Are these URI's a matter of a pure RESTful implementation vs implicit content negotiation?

我的想法是，通过在 URI 中显式使用 API，客户端会期望一种本质上不令人愉悦的超媒体数据格式，并且可以更轻松地使用，而无需显式设置 Accept header 。换句话说，API 暗示您需要 JSON 或 XML，而不是 XHTML。

Is this a matter of separating resource representations logically on the server side?

对于为什么有人会用 API 子域设计 URI，我能想到的唯一理由是，基于我的假设，这是一种扩展技术，它应该使多层服务器基础设施中的路由请求加载变得更容易。也许存在反向代理剥离 header 的情况？我不知道。不同的服务器处理不同的表示？

也许子域仅用于外部使用者，以便服务器避免内部使用的开销。速率限制？

Am I missing a point?

我提出的设计将尝试通过设置适当的 header 、适当使用 HTTP 动词并以我认为在 URI 中包含“API”的方式表示资源来遵循 RESTful 实践。

Why would someone design a RESTful API with 'API' in the URI?

或者可以吗？也许我不理解这种设计的问题是，只要它遵循某种可能不会导致 RESTful API 实现但接近的规范组合，没关系？ 给键盘猫剥皮的方法不止一种。 HATEOAS相关？

<小时/>

更新:在研究这个主题时，我得出的结论是，考虑 REST 的想法很重要，但不要将其视为一种宗教。因此，URI 中是否包含“api”更多的是一个设计决策，而不是一个坚定的规则。如果您计划公开公开网站的 API，那么使用 api 子域来帮助处理应用程序的逻辑是个好主意。我希望有人能贡献自己的见解供其他人学习。

Answer 1

我会(并且已经)这样做是为了将其与“网站”基础设施分开，因为它可能会具有更高的负载并需要更多的基础设施 - 每天执行数百万个 API 调用比将其引入要容易得多页面浏览量，因为您拥有 n 个网站/公司的全部负载以及他们的努力和吸引力，集体甚至在某些情况下单独他们将吸引比您自己更多的流量。