彦祖们，这种 API 接口设计有哪些利弊？

最近在复刻一些产品做练手，发现了不少新产品的 web api 接口很有意思。两个典型参考对象是 wolai.com 和 todoist.com

传统上，我们会根据业务需求给不同的业务设计开发出不同的 api 接口出来给前端调用。

比如某个系统叫 V2EX，包含了对帖子的增删改查，我们往往会创建

/article/create
/article/update
/article/delete
/article/get/:id
/article/list/get

等接口。

然后处理分类还有
/category/create
/category/update
等等。

当然其中还有一些可以合并的，具体不一而足，因人而异。

但我最近看到了这样一些接口。使用方法类似于

/article

然后 payload 为

{ "resource_type": "article"， "transaction": [{ "requestId": "some kind of uuid" "command":"updateArticle", "args": { "articleId": some int or uuid, "content": "some string", "blahblah": "blahblah" } }] } 

这个 payload 本身不难看懂，其中 transaction 是个数组，可以一次包含多个指令。

这个让我想起来以前我们有的时候开的玩笑，说根本不需要写很多接口，只要一个接口，传不同的参就可以干所有的事。现在看来这个玩笑不仅被人真的这么做了，还给了很完善的事务概念。

但我仍然有些困惑，这样的模式真的很好用吗？

我能想到一些优势，比如前面可以是一个很薄的 controller， 后面随着 args 的不同调用不同的 service 处理。service 可以很轻松的切换版本，不需要担心和前端的对接。队列在后端的应用也是显而易见的。

对前端来说，也不再需要看 N 个接口的文档，大多数接口会统一起来有一套标准，只要定义约定好相关的行为和参数就可以。

但这样的接口调用，是不是本身就太复杂了呢？ 我大概想了下，似乎没有看到很明显的收益。我大概看了下相关的前端，有这样一个特性。

比如说列表页，我新增一个内容，传统模式是先 create，然后再获取 list，进行 data 更新。 现在会改成先操作本地 data，直接在 list 里 append，然后再发一个事务描述，告诉后端去做对应的相关操作。

我甚至在某个 app 中遇到过事务失败的问题，然后造成了多端登录的情况下有一个端死活同步不了（ Todoist，事务 ID 对不上，死活不能同步数据。）

就想问问各位大佬，这种接口设计除了我自己臆想分析的特征，还有什么别的是我没考虑到的吗？