像乐高积木一样构建API：一个接口专家的几点建议

最新推荐文章于 2024-04-19 18:47:59 发布

互联网架构

最新推荐文章于 2024-04-19 18:47:59 发布

阅读量181

点赞数

本文基于 Matthias Biehl 在 2016 Nordic API平台峰会的演讲，视频请参看 [9]

笔者之前写了很多篇关于 API 的文章 [1][2]，今天这篇将着重于如何结合业务模型来构建 API。

显然，这个话题对于不同的公司而言是完全不同的。在一些公司，API 是他们最核心的产品。然而对于大多数企业，API 并不被重视，就像业务的边缘产品。

来自 API University（http://www.api-university.com）的 API 咨询师 Matthias Biehl 认为，对于业务发展，API 是一个非常关键的驱动因素，甚至直接影响公司的商业变现模型。

API 和乐高积木有什么相似之处？

相信我们大多数人在儿童时期都喜欢玩乐高积木。乐高积木的真正乐趣和吸引力在于，尽管包装盒外面都带有示意图片，但你最终都可以随心所欲得搭出各种样子或造型。

引用前一篇文章[3]，“……对 API 的最佳解释就是它们像乐高积木一样……”。我们可以用创造性的方式来组合它们，而不用在意它们原本的设计和实现意图。

你可以发现很多 API 和乐高积木的相似之处：

标准化：通用、标准化的组件，作为基本的构建块（building blocks）；
可用性：强调可用性，附有文档或使用说明；
可定制：为不同功能使用不同的 API；
创造性：能够组合不同的 API 来创造混搭的结果；

乐高和 API 都有超简单的界面/接口，并且借助这样简单的界面/接口，它可以非常直观、容易、快速得构建。

虽然乐高和 API 一样可能附带示意图片或使用文档，大概描述了推荐玩法或用途，但真正令人兴奋的结果或收获恰恰是通过创造力产生的。

让我们仔细地思考下上述的提法。在很多情况下，API 的使用者构建出了 API 的构建者超出预期的服务或产品，API 使用者想要的，和 API 构建者认为使用者想要的，这二者之间通常有个断层。事实也确实如此，在 IoT 领域，我们使用 API 创造出了一些非常有创造性的使用场景[4]。

API 和价值链

Matthias 建议，使用 API 创造价值的最简单的方法，就是看看 API 在价值链中适合或可能适用什么位置，也就是 API 在业务的哪方面会产生广泛影响。

API 使用者的目标是将一个移动应用或者在线服务组合在一起，并将其提供给最终用户。

以 Uber 为例，它依赖多种 API[5]：

地图服务：Google 地图；
VoIP 和短信通知服务：Twilio；
支付服务：Braintree；
人脸识别：Microsoft Face API[6]

API 的所有者不仅需要考虑他们的 API 可以直接用来做些什么，还要考虑一些潜在的组合下的场景。只有这样，他们才能确保 API 更易于使用和集成。这能帮助 API 使用者也就是应用程序开发人员更好地发挥创造性，也会使得 API 在价值链中价值最大化。

API 和设计思维

Matthias 列出了 API 开发人员最关心的两个问题：

我如何通过我的 API 赚钱？
我如何使我的 API 容易使用？

同时，他也补充了一个他认为更应该关心的问题：

我创建的 API 是否是开发人员真正需要的？

可以看出来，后两个问题是解决第一个问题的关键所在。

就像产品开发中的需求分析一样，首先我们要了解开发人员真正需要的 API 是什么样，Matthias 建议可以遵循下面步骤：

640?wx_fmt=png

上图是 API 业务生命周期模型，看起来像很多 Lean Startup 中提到的模型。这样往复思考－尝试－验证－回顾的过程缓慢且充满坎坷，但是请记住 “没有任何有用的东西是在 Hackathon 上创造出来的”。

API 和业务模型白板

一旦确定了 API 使用者的需求，就可以更容易地确定 API 适合的商业模式。这里我们建议使用业务模型白板（Business Model Canvas[7]）以可视化的方式来迭代执行整个模型。

640?wx_fmt=png

业务模型白板是一种与 Lean Startup 相关的方法论，它使用标准化模板以最简单的术语来定义和描述业务模式。

这里使用一个电信企业的例子，来展示如何使用业务模型白板来设计 API：

640?wx_fmt=jpeg

API 的业务模型由两部分组成：API 提供方的业务模型和 API 使用方的业务模型。这二者是紧密相连的，寻找 API 为使用方的业务模式提供的价值所在，能进一步帮助 API 提供方确定赚钱的方式。

最后的想法

当前构建 API 的一个重要问题是，许多公司在考虑清楚 API 在价值链中的位置以及业务模型之前，就先将 API 与其产品一起构建出来。

正如所有商业人士都清楚的那样，在没有进行任何市场调查和规划前，就启动一个项目[8]，是一个非常错误的做法。

在规划新 API 时应关注这些问题：

构建的 API 是否是开发人员所需要的？
如何构建一个可以解决这些需求的 API？

好的 API 就像乐高积木：易于使用，小朋友喜爱它。如果你正在构建新的 API 或重构现有的 API，在你的桌面放一块乐高积木，希望它可以时刻提醒着你。

参考链接

[1] http://nordicapis.com/top-5-api-monetization-models/
[2] http://nordicapis.com/how-to-grow-and-profit-using-a-freemium-api-monetization-model/
[3] http://nordicapis.com/legos-api-strategy-resourcing-developers-building-business-case/
[4] http://nordicapis.com/the-power-of-unexpected-iot-apis/
[5] https://nordicapis.com/4-apps-rely-apis-survival/
[6] https://www.microsoft.com/cognitive-services/en-us/uber
[7] https://en.wikipedia.org/wiki/Business_Model_Canvas
[8] http://nordicapis.com/7-lessons-learned-building-an-api-startup/
[9] https://youtu.be/OioGGOU9RQc