本文主要是介绍Kevin Montrose谈StackExchange API的历史与错误，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
本文来源于我在InfoQ中文站翻译的文章，原文地址是：http://www.infoq.com/cn/news/2011/08/StackExchange-API为现有站点创建公开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
这篇关于Kevin Montrose谈StackExchange API的历史与错误的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
