我有一个带有两个主要包的RESTful API的应用程序。
一个包使用简单的CRUD操作公开DB模型。它的一般目的只是为其他服务和前端应用程序提供一些基本数据。它还提供了版本控制,以避免更新中的另一个服务错误:/api/v{number}/
其他包使用大量DB查询来表示业务逻辑,以避免前端聊天行为。它只用于前端应用程序。没有版本控制。
这两个包都使用相同的ORM模型和DB。
这个应用程序是内部使用,没有外部客户或用户。只有我们公司。
主要的问题是如何在URL中表示这些特性。有两种选择:
1.对两个包使用相同的URL根:
domain.com/api/v{number}/...
2.使用不同的URL根:
用于简单CRUD的domain.com/api/v{number}
用于业务逻辑api的domain.com/views/
First option.
1. Our developers can use API without db structure knowledge, just API documentation.
2. Front-end developers just remember names, not location.
1. Naming problems. Same entity has different db/business representation. It will cause ugly ambiguous names like _entity\_infos, entity\_details, entity\_deep_ etc.
2. Permanent `/v1/` in business API URLs, because there is no versioning.
第二选择。
1. There is no URL versioning for business API.
2. There is no naming problems.
1. There is no abstraction. You know when is single table used or heavy business logic.
2. Front-end app uses different API roots with same resource name. It may be confusing, especially for new developers.
正如你所看到的,一个人的优点是另一个人的缺点。
我想听听有争议的意见以及一些相关的联系。谢谢。
发布于 2017-03-15 22:36:33
从减少风险的角度来看,备选案文2比备选案文1更可取。
如您所知,前端开发人员永远不能直接访问业务数据。如果您的CRUD API允许这样做,并且您的前端开发人员使用它,则可能导致不可逆转的数据损坏以及严重的声誉和财务损失。
任何访问业务数据的东西都需要经过严格的开发和测试过程。这种测试不是由前端开发人员执行的(相信我-我知道)。因此,业务逻辑开发人员应该是唯一使用CRUD API的人。如果前端开发需要业务逻辑目前没有提供的数据操作,则需要规划、开发和测试API中的新方法。
即使业务逻辑调用只执行一个CRUD API调用,前端开发人员也不需要知道。他们所感兴趣的是,他们所要求或提交的数据将以正确的方式处理。如果更改了数据库模式(例如,在数据库升级期间),只需要更新一个API,而不需要搜索整个前端的API调用。如果您有引用最新版本的latest别名,并且业务逻辑使用它而不是v1等,则可以更新CRUD,而无需重写业务逻辑API。Atlassian为其应用程序开发的REST API使用这种别名。(请看一下这里。)查看'URI结构‘部分)
将不同URL上的两个API分离清楚地表明,它们针对的是不同的目标。不让前端开发人员知道CRUD会通过模糊的方式带来一定程度的数据安全性。他们不知道的东西不能咬他们。
你总是需要考虑未来。您说应用程序仅供“内部”使用,但如果您的公司收购了一家新业务并开始使用API,怎么办?你真的想让他们直接看数据吗?如果允许对API进行公共访问,该怎么办?你当然想让Joe和他的脚本-孩子朋友直接在你的数据库里闲逛。分离URL使这更容易实现,因为您可以阻止对CRUD API的访问,而不必担心是否有后门路径通过它。
https://stackoverflow.com/questions/42821278
复制相似问题