rest - REST API多个根URL

我有一个带有两个主要软件包的RESTful API的应用程序。

一个软件包使用简单的CRUD操作公开DB模型。它的一般目的只是为其他服务和前端应用程序提供一些基本数据。并且它已进行版本控制以避免更新时出现其他服务错误：/api/v{number}/

其他包表示具有大量数据库查询的业务逻辑，以避免前端聊天行为。它仅由前端应用程序使用。没有版本控制。

两个包都使用相同的ORM模型和DB。

此应用程序供内部使用，没有外部客户或用户。只是我们的公司。

主要问题是决定如何在URL中表示这些功能。有两种选择：

1。对两个包使用相同的URL根目录：

domain.com/api/v{number}/...

2。使用不同的URL根：

domain.com/api/v{number}表示简单的CRUD api

domain.com/views/用于业务逻辑api

第一个选项。

优点：
1. 我们的开发人员可以使用没有数据库结构知识的API，只需API文档。
2. 前端开发人员只记得名字，而不是位置。
缺点：
1. 命名问题。同一实体具有不同的数据库/业务表示。它会导致丑陋的模糊名称 entity_infos，entity_details，entity_deep 等
2. 商业API网址中的永久/v1/，因为没有版本控制。

第二个选项。

优点：
1. 商业API没有网址版本。
2. 没有命名问题。
缺点：
1. 没有抽象。您知道何时使用单个表或繁重的业务逻辑。
2. 前端应用程序使用具有相同资源名称的不同API根。这可能会令人困惑，特别是对于新开发者而言。

正如你所看到的，一方的优点是另一方的利弊。

我希望听到有争议的意见以及一些相关链接。感谢。

从风险降低的角度来看，选项2优于选项1。

如您所知，前端开发人员永远不应该直接访问业务数据。如果您的CRUD API允许这样做，并且您的前端开发人员使用它，那么可能会发生不可逆转的数据损坏，以及对公司的严重声誉和财务损失

访问业务数据的任何内容都需要经过严格的开发和测试过程。这种测试不是由前端开发人员执行的（相信我 - 我知道）。因此，业务逻辑开发人员应该是唯一使用CRUD API的人。如果前端开发人员需要业务逻辑当前未提供的数据操作，则需要计划，开发和测试API中的新方法。

即使业务逻辑调用只是执行单个CRUD API调用，前端开发人员也不需要知道。他们感兴趣的是他们请求或提交的数据将以正确的方式处理。在数据库模式被更改的情况下（例如，在数据库升级期间），仅需要更新单个API而不是使整个前端搜索API调用。如果您的别名为latest引用最新版本，并且业务逻辑使用该版本而不是v1等，则可以更新CRUD API等，而无需重新编写业务逻辑API。 Atlassian为其应用程序开发的REST API使用此别名。（请查看here。查看＆＃39; URI结构＆＃39; 部分）

将不同网址上的两个API分开，清楚地表明它们针对不同的目标。不要让前端开发人员知道CRUD API URL通过默默无闻带来了一定程度的数据安全性。他们不知道的事情不能咬他们。

你总是需要考虑未来。您说该应用程序仅供内部使用＆＃34;，但如果您的公司获得新业务并且他们开始使用API会怎么样？你真的希望他们直接看数据吗？如果允许公共访问API怎么办？你当然希望Joe Bloggs和他的脚本小子朋友直接在你的数据库里闲聊。分隔URL可以更容易实现，因为您可以阻止访问CRUD API而无需担心是否有后门路由到它

REST API多个根URL

1 个答案: