logo标签列表

为什么有人会在URI中设计一个带有“API”的RESTful API？

web-servicesrestscalabilityuriapi-design
16

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

假设这些设计正确使用了Accept和Content-type头部，用于XHTML、JSON或任何格式之间的内容协商。

这些URI是纯RESTful实现与隐式内容协商的问题吗？

我认为，通过在URI中显式使用API，客户端将期望一种不是本质上适合人类阅读的超媒体数据格式，并且可以更轻松地消费而无需显式设置Accept头部。换句话说，API暗示你期望JSON或XML而不是XHTML。

这是在服务器端逻辑上分离资源表示的问题吗？

我能想到的唯一理由是，为什么有人会使用API子域名设计他们的URI，是因为基于我的假设这是一种扩展技术，它应该使多层服务器基础架构中的路由请求负载更轻松。也许存在反向代理被剥离头部的情况？我不知道。不同的服务器处理不同的表示形式？
也许子域名仅用于外部消费者，以使服务器避免来自内部使用的开销。速率限制？

我错过了什么吗？

我的设计尝试遵循RESTful实践，通过设置适当的头部、适当使用HTTP动词并以我认为包括“API”在URI中是多余的方式来表示资源。

为什么有人会在URI中设计RESTful API时加上“API”？

或许他们可以吗？也许我不理解这个设计的问题在于，只要它遵循某些规范的组合，就算不符合RESTful API实现，也没有关系？有多种方法可以解决问题。 与HATEOAS相关吗？

更新：在研究这个话题时，我得出结论，考虑REST的思想很重要，但不应将其视为一种信仰。因此，在URI中是否有“api”更多地是一种设计决策，而不是一条坚定的规则。如果您计划公开展示网站的API，则最好使用api子域来帮助处理应用程序的逻辑。希望有人能贡献他们的见解供其他人学习。
4个回答
11

我会（并且已经）这样做，将它与“网站”基础架构分开，因为它可能会有更高的负载和需要更多的基础设施-每天处理数百万API调用比获取页面浏览量容易得多，因为你有n个站点/公司的全部负载和它们的努力和动力，集体地甚至在某些情况下个别地他们会比你自己吸引更多的流量。

5
这是我对你的问题的理解和看法：
这些URI并不是任何官方文档的一部分（据我所知），通常由开发人员/团队自行决定。例如，Zend Framework使用一些实用类来检测XHR请求以及响应应该如何返回。诚然，ZF并不是纯粹的RESTful设计（或者说大多数PHP应用程序都不是），但即使在PHP中也仍然有可能编写这样的设计。
我经常看到在URL中使用api，当预期返回的数据确实不适合直接用于向最终用户显示时。然而，这通常是一个设计决策，不一定是一个暗示的标准。
这是一种在服务器端逻辑上分离资源表示的问题吗？

多多少少。例如，执行PUT请求时，接口不一定需要完全刷新，通常一个简单的响应消息就足够了。虽然这个响应消息是视图的一部分，但它不是整个视图。因此，例如，http://domay.com/users/将返回用于管理用户（或其他内容）的界面，http://domain.com/users/api将执行操作并返回界面更新（无需重新加载页面）。

我有什么遗漏吗？

嗯，没有。由于在URL中使用api是一个设计决策，您在这里没有遗漏任何东西。通过适当的标题，

http://domain.com/users/api/get
http://domain.com/users/get
http://domain.com/users/

所有这些都可以是有效的RESTful请求。

为什么有人会在URI中设计一个带有“API”的RESTful API？

简而言之，是为了有一个URL命名约定。这样，在查看日志、文档等请求时，人们就能理解它的目的。

5
请注意，大多数框架（如django、RoR等）都提供了基于URL的路由功能。您可能需要为API和HTML响应分别编写不同的视图来管理身份验证、限制检查和其他特定内容。
为了实现隐式内容协商，额外设置一个基于HTTP头的路由系统通常不值得花费这样的精力。
4

用户可见的网页URL受到站长、设计师、公司组织、营销、时尚、技术等诸多影响因素的影响。

而API则应该保持稳定。通过使用子域名，您可以将API与整个网站以及它在未来可能经历的变化隔离开来。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接