Rails 接口的功能粒度

thxagain · 2016年01月11日 · 最后由 michael 回复于 2016年02月09日 · 3289 次阅读

Hi 大家好,我又来啦。 这次是想讨论一下接口设计的功能粒度。

假设我有两张表,books图书概要表以及book_details图书详情表。 例如有这么一个需求:录入图书,如果是外文书,可能只录入概要就可以了,如果是中文书,还要录入图书详情。 那我是应该提供两个接口:POST /books 以及POST /book_details,让接口调用方根据自己的需求调用, 还是应该提供一个接口: POST /books_instore呢?

我仔细想了想,似乎两种做法都有道理: 第一种做法符合 REST 风格,接口作用单一,逻辑上比较清晰。 第二种做法呢,减少了接口调用方的工作,并且只有一次请求,减少了网络传输的时间。

那万一有更复杂的情况,如果一个需求,既包含了 POST 创建,又包含了 PUT 更新操作,还可能会有 DELETE,是应该用一个接口实现它呢,还是三个接口呢?

想请问一下社区里有经验的同学,在接口的功能设计上,粒度的粗细是如何控制的。

还是说,这种情况是需要根据实际业务情况来看的。 请社区里的同学分享下自己的接口设计经验。

问题 1.建议用一个借口。 问题 2.建议分成多个接口。 API 设计的粗细力度取决于是否好理解和功能重用。

接口粒度的细分除了要考虑职责单一外,还得考虑多个操作是否应该在同一事物中。

开放给第三方就给两个,要求灵活,稳定 开放给自己的 app 用,就给一个,要求请求少

@jimrokliu 关于是否好理解,其实两种方案,看起来都挺容易理解的。

站在接口调用方的角度,自然是希望接口越少越简单越好,如果有一个接口,可以满足所有需求,当然是最好的啦。不需要管后端是更新、删除或者新增操作,涉及到几张表,调用方当然是希望这种实现上的业务逻辑越少接触越好。

站在接口实现方的角度,则是希望接口的功能能够清晰明确。可是拆分得过细则必然会导致接口调用次数增加,HTTP 请求还是挺耗时的。

其实就是希望找到一个平衡点。

@uudui 事物 => 事务?嗯,有道理,是要考虑事务性。

@azhao 开放给自己内部同学们用,暂时是两套接口都做了。 因为有的地方只会调用得到粒度细的接口,有的地方则希望调用粒度粗的接口。

这 books 和 details 是 one <-> one 的关系吧? 有必要拆开吗? 合并 books 和 book_details 为一个表是否更简洁一些? 如果可以合并, 就无需考虑此类问题了.

@chenjau 现在实际情况确实因为某种原因拆开了,比如 details 表中的字段比较多,如果合并在一起,可能只有少量的中文书的数据需要这么多字段,其他大部分外文书的数据这些字段都空着...

我自己用 restful 直接最小粒度,让前端自己 handle 多次 promise 调用,第一次这么干,不然各种依赖逻辑都要进后端基础逻辑层,问题就是事务这里,非强事务功能几乎可以忽略了。

  • 我想拆出基础逻辑 DB 包,感觉项目不大,省了
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册