BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Kevin Montrose谈StackExchange API的历史与错误

| 作者 Jonathan Allen 关注 595 他的粉丝 ,译者 张龙 关注 14 他的粉丝 发布于 2011年8月29日. 估计阅读时间: 3 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

为现有站点创建公开API总是一件很有风险的事情,而且StackExchange的开放编辑策略则将这种风险更进了一步。在最近发表的一系列文章中,Kevin Montrose谈到了关于StackExchange API的决策以及从中得到的经验与教训。

在开始设计API时,他们就已经设定好了目标与约束。比如说,他们的一个主要目标就是“让开发者无需查阅其站点”。StackExchange成员所遵循的内容许可协定cc-wiki可以让第三方重用站点上的内容,但在该API发布前,并没有很好的方式进行批量访问。最大的一个约束在于API是只读的,Kevin说到

显然,写操作是非常危险的。不仅仅出现在有Bug的认证上,比如有人以Jeff Atwood登录,删除了大量的内容,这会让我寝食难安。更重要的是(也是更危险的),在疏于指导的情况下,这会导致人们发布大量的垃圾信息。

我们为了确保Stack Exchange内容的质量付出了艰辛的努力(我们关闭了不满足标准的整个站点)。未经深思熟虑的写操作API会导致很多问题,因此我们在1.0中并没有将其添加进来。不过,我们有可能在3.0中将其添加进来。

Kevin提到了一些关键的设计点:

  • 矢量化请求:“无论何时,如果我们能接受一个id,那么我们就可以接受100个”
  • 压缩的响应:我们使用GZIP对响应进行压缩,即便客户端并没有要求压缩我们也会这么做
  • 排序与过滤:“大多数端点可以接收sort、min、max、fromdate以及todate参数进行查询”

但人们更感兴趣的是他们所犯的错误。比如说,默认情况下返回总数的决定。

总数对于分页控件的渲染很有用,count(*)查询就是如此(比如说人们对我的评论的投票数等等);从这个角度来说,total字段本身并没有错。但默认情况下返回它则毫无疑问是不对的。

问题在于总数是有用的,但却并非总是如此。很多时候,查询形式是这样的:“返回标记为X的最近的N个问题/答案/用户,或是返回你所拥有的前N个问题/答案并且根据S排序”。这些常见的查询与总数没有任何关系,但每次却都要返回总数,这就需要付出代价。

另一个问题在于对隐式类型的使用。相对于显式说明返回哪个数据类型来说,客户端开发者需要从现有的字段中进行推断。无论在何种语言中这都是非常恼人的问题,但对于静态类型语言来说更是如此,因为开发者需要将这些无名类型映射到实际的类上。

暂且不表其他的错误,让我们使用Kevin提到的最后一个错误来作为结论,那就是浪费的请求量。为了防止过度使用API,他们使用了与Twitter API一样的配额。

这实在是太浪费带宽了,与Twitter不同,我们的配额还是相当慷慨的(每天10,000个请求)并且不是动态的。对于total字段来说,很多应用并不需要关注配额(除非超过了,但这种情况很少发生),但如果每次请求都获取该字段则需要付出代价。

查看英文原文:Kevin Montrose on the History and Mistakes of the StackExchange API

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

真是好例子 by Jeffrey Zhao

Stack Exchange不错。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

1 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT