Season 2: 指标
S2E1: 如何为 OpenAPI 的指标分类
作为一个好的 OpenAPI 业务同学,应该同时关注 OpenAPI 的基建指标和用户相关指标,从而更好的通过指标,数据驱动优化业务。
Season 2: 指标
作为一个好的 OpenAPI 业务同学,应该同时关注 OpenAPI 的基建指标和用户相关指标,从而更好的通过指标,数据驱动优化业务。
Season 1: 杂文
本期是 API Letter 的第二期,天津下起了小雨,一场秋雨一场寒,我在雨中为你撰写这封 Newsletter。 任何一个开放平台类产品,要解决的问题都是如何在现有的平台能力之上,开放一些能力给到第三方开发者,帮助第三方开发者开发应用,拓展体验,如果我们可以降低开发者在完成开放能力接入所需的时间,我们就可以让开发者有更多的时间去构建属于自己的业务逻辑,拓展平台之上的应用生态和开发者体验。 API 的设计质量、文档质量和错误处理信息的质量可以非常明显的影响到 API 的使用体验。但这些体验却很难通过我们在软件工程领域所使用的各种性能指标来衡量。我们可以通过一些专业的、对于 API 有判断能力的人来完成对于 API 质量的评估和优化的引导,但这件事并不利于持续发展和长期迭代。我们需要一个靠谱的指标,来引导我们持续性的、规模化的进行 API 本身的优化和迭代。 在这个问题上,Slack 给出了自己的答案 —— Time to First Hello World(TTFHW), API 服务提供商 readme.com 则提出了一个类似的概念 Time to