我有一个带有两个主要软件包的RESTFUL API的应用程序。
一个软件包用简单的CRUD操作揭示了数据库模型。它的一般目的只是为另一个服务和前端应用提供一些基本数据。并且具有版本控制以避免更新上的其他服务错误：/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
第一个选项。
-
PROS：
- 我们的开发人员可以在没有DB结构知识的情况下使用API，只有API文档。
- 前端开发人员只记得名称，而不是位置。
-
cons：
- 命名问题。相同的实体具有不同的DB/业务代表。它会引起丑陋的歧义名称 entity_infos，entity_details，entity_deep 等。
- 业务API URL中的永久
/v1/，因为没有版本化。
第二个选项。
-
PROS：
- Business API没有URL版本控制。
- 没有命名问题。
-
cons：
- 没有抽象。您知道何时使用单表或重型业务逻辑。
- 前端应用使用具有相同资源名称的不同API根。这可能会令人困惑，特别是对于新开发人员。
您可以看到，一个人的优点是另一个的弊端。
我想听听有争议的意见以及一些相关的链接。谢谢。
从风险降低的角度来看，选项2比选项1更可取。
您知道，前端开发人员绝不能直接访问业务数据。如果您的CRUD API允许这一点，并且您的前端开发人员使用它，则可能导致不可逆转的数据腐败以及对公司的严重声誉和财务损失。
任何访问业务数据的事物都需要经过严格的开发和测试过程。这种测试不是前端开发人员执行的（相信我 - 我知道）。因此，业务逻辑开发人员应该是唯一使用CRUD API的开发人员。如果前端开发人员需要业务逻辑当前未提供的数据操作，则需要计划，开发和测试API中的新方法。
即使业务逻辑调用只是执行单个CRUD API调用，前端开发人员也不需要知道。他们感兴趣的只是他们要求或提交的数据将以正确的方式处理。如果更改数据库模式（例如，在数据库升级期间），则只需要更新一个API，而不是整个前端搜索API调用。如果您对latest的别名引用了最新版本，并且业务逻辑使用而不是v1等，则可以更新CRUD API，而无需重新编写业务逻辑API。由Atlassian开发的REST API用于其应用程序使用此混溶。（请在此处查看。请查看'URI结构'部分）
在不同URL上将两个API分开清楚地表明它们针对不同的目标。不让前端开发人员知道CRUD API URL通过默默无闻带来一定程度的数据安全性。他们不知道的不能咬他们。
您总是想考虑未来。您说该应用程序仅用于"内部"，但是如果您的公司获得新业务并且他们开始使用API怎么办？您真的希望他们直接查看数据吗？如果允许向API进行公共访问该怎么办？您当然希望Joe Bloggs和他的Script-Kiddie朋友直接在您的数据库中戳戳。分开URL可以更容易实现，因为您可以阻止对CRUD API的访问，而不必担心是否有后门路线