Hi 大家好，我又来啦。 这次是想讨论一下接口设计的功能粒度。
假设我有两张表，books图书概要表以及book_details图书详情表。
例如有这么一个需求：录入图书，如果是外文书，可能只录入概要就可以了，如果是中文书，还要录入图书详情。
那我是应该提供两个接口：POST /books 以及POST /book_details，让接口调用方根据自己的需求调用，
还是应该提供一个接口： POST /books_instore呢？
我仔细想了想，似乎两种做法都有道理： 第一种做法符合 REST 风格，接口作用单一，逻辑上比较清晰。 第二种做法呢，减少了接口调用方的工作，并且只有一次请求，减少了网络传输的时间。
那万一有更复杂的情况，如果一个需求，既包含了 POST 创建，又包含了 PUT 更新操作，还可能会有 DELETE，是应该用一个接口实现它呢，还是三个接口呢？
想请问一下社区里有经验的同学，在接口的功能设计上，粒度的粗细是如何控制的。
还是说，这种情况是需要根据实际业务情况来看的。 请社区里的同学分享下自己的接口设计经验。
@jimrokliu 关于是否好理解，其实两种方案，看起来都挺容易理解的。
站在接口调用方的角度，自然是希望接口越少越简单越好，如果有一个接口，可以满足所有需求，当然是最好的啦。不需要管后端是更新、删除或者新增操作，涉及到几张表，调用方当然是希望这种实现上的业务逻辑越少接触越好。
站在接口实现方的角度，则是希望接口的功能能够清晰明确。可是拆分得过细则必然会导致接口调用次数增加，HTTP 请求还是挺耗时的。
其实就是希望找到一个平衡点。
这 books 和 details 是 one <-> one 的关系吧？有必要拆开吗？合并 books 和 book_details 为一个表是否更简洁一些？如果可以合并，就无需考虑此类问题了。
@chenjau 现在实际情况确实因为某种原因拆开了，比如 details 表中的字段比较多，如果合并在一起，可能只有少量的中文书的数据需要这么多字段，其他大部分外文书的数据这些字段都空着...
我自己用 restful 直接最小粒度，让前端自己 handle 多次 promise 调用，第一次这么干，不然各种依赖逻辑都要进后端基础逻辑层，问题就是事务这里，非强事务功能几乎可以忽略了。
- 我想拆出基础逻辑 DB 包，感觉项目不大，省了