最近在复刻一些产品做练手,发现了不少新产品的 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 对不上,死活不能同步数据。)
就想问问各位大佬,这种接口设计除了我自己臆想分析的特征,还有什么别的是我没考虑到的吗?
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.