数据API 案例 开发者 关于
掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道

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

本文基于 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 建议可以遵循下面步骤:

1389-640.jpg.jpg

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

API 和业务模型白板

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

1390-640.jpg.jpg

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

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

1391-640.jpg.jpg

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

最后的想法

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

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

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

  • 构建的 API 是否是开发人员所需要的?

  • 如何构建一个可以解决这些需求的 API?

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

参考链接

本文作者 Art Anthony,由 James 翻译,转载请注明出处,技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式


长按二维码 关注「高可用架构」公众号

原文来自:高可用架构

掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道
像乐高积木一样构建API:一个接口专家的几点建议
发布:2017-04-28

本文基于 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 建议可以遵循下面步骤:

1389-640.jpg.jpg

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

API 和业务模型白板

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

1390-640.jpg.jpg

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

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

1391-640.jpg.jpg

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

最后的想法

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

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

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

  • 构建的 API 是否是开发人员所需要的?

  • 如何构建一个可以解决这些需求的 API?

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

参考链接

本文作者 Art Anthony,由 James 翻译,转载请注明出处,技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式


长按二维码 关注「高可用架构」公众号

原文来自:高可用架构

电话 0512-88869195