将 API 视为产品这一概念在 API 领域迅速普及，越来越多的组织开始看到在开发 API 时使用产品管理原则的好处。这种方法包括对您的 API 产品组合投入与您团队交付的任何其他软件产品相同的关注和规划。
这也是最近在 Nordic API Austin API 峰会上流行的概念。该会议以一些演讲为特色，涉及该主题，包括：来自 Vanick Digital 的 Pete Clare 的为什么产品化是解锁 API 价值的关键，以及来自 Paypal 的 Rahul Dighe 的嵌入 API 即产品文化。
SmartBear 很荣幸成为为期三天的活动的赞助商，我有机会与许多演讲者和与会者讨论这个主题以及 API 领域的其他许多趋势。在这次采访中，我采访了 Chris Busse，他是 APIVista 的首席技术官，他在那里帮助客户设计、发布和支持 API。 我两年前做过类似的采访，因此很高兴再次与他联系，了解他自上次谈话以来获得的新见解。
Chris 长期以来一直是 API 产品方法的倡导者，并且亲身体验了这种方法带来的挑战和机遇。在我们的对话中，我们讨论了将 API 视为产品的重要性、“设计优先”API 开发的作用，以及他通过在 APIVista 工作中观察到的其他趋势。
您可以在下面观看和阅读我们的完整对话
我很高兴能与 APIVista 首席技术官 Chris Busse 一起。Chris，到目前为止，会议怎么样？
太棒了！我从会议中真正欣赏的一点是对待 API 作为产品的关注。这非常符合我的想法。这是我喜欢在 API 设计中使用的方法，无论是和我的客户还是在以前的工作中。
我不知道“潮流”是否合适，但我们看到越来越多关于这个概念的讨论，而且越来越多的人不仅能够分享将 API 视为产品的理论，而且实际上能够分享他们的成功经验。
说“你应该这样做”是一回事。但是说“我们是这样做的，我们发现了成功，这是我们学到的东西。这是你可以应用的，以及如何根据我们的经历更快地到达那里”是另一回事。
我知道您是 API 的“合同优先”或“设计优先”方法的坚定拥护者。您能否详细说明设计优先的思维方式如何应用于产品方法？
我认为 设计优先思维是 API 产品方法的关键，因为您必须知道您为谁设计。过去一年，随着我们在 APIVista 发展和招聘开发人员，我了解到 API 开发人员通常可以分为三类。
第一类是可能正在从事全栈工作的人。他们正在构建的这些 API 实际上是为他们自己准备的。也许这样他们可以向 Angular 前端公开，或者可能是移动前端，但他们正在构建 API。仅在该领域工作的开发人员可能对 API 作为产品的概念没有那么多了解。
该进展中的下一层级是正在构建 API 的开发人员，也许他们没有做用户界面或前端，但是他们可以转身与可以做的人交谈。在这种情况下，API 是为他们认识的人准备的，他们不需要那种程度的关心或文档来理解，并且可以通过口头传达价值。当我们在讨论将 API 视为产品时，他们可能不需要我们经常谈论的那种精度。
第三种是为您的直接圈子之外的人构建 API。这可能是大型企业中我甚至不知道他们在组织结构图中位于何处的人，也可能是最终成为完全陌生人的合作伙伴。
当我们认为 API 是一种产品时——人们通常喜欢使用 API 这个术语，并说 API 应该是一种产品——但我确实认为这种产品化是需要时间和地点的。当您为陌生人构建 API 时，产品思维就变得至关重要。最终消费者现在是我们的客户。
了解消费的背景也很重要。最终消费者是开发人员，但该开发人员正在为另一个客户使用您的 API，因此您还需要了解这方面的信息。我们已经开始与一些向合作伙伴发布 API 的客户使用的词是“共同创造”的概念。我们正在共同为您的客户创造一些东西。
因此，我不仅需要了解您将如何使用我的 API 产品，而且我想知道它正在驱动的业务价值。您正在为用户创建什么用户体验？这样，我也可以思考“这对我的后端系统有什么影响？”这与接口有关，但也涉及这些 API 的性能和非功能性要求。
即使只是了解最终消费者的业务周期——他们的业务周期是否会受到季节性影响，他们是否会看到流量高峰？它确实可以帮助您考虑您正在交付的各个方面，以及 API 需要公开的功能。
API 的产品思维需要付出很多努力，您希望最大化这种思维的影响。我认为这是一种非常有趣的看待方式，它也为应用产品思维提供了一个框架。
要让某样东西成为产品，您需要有客户。如果您是为自己构建，是的，您就是您自己的客户。也许您需要记下您做了什么、为什么这样做，但您不是在那里有客户。因此，我认为我们——当我非常兴奋地对待 API 作为产品时——总是要记住将精力花在最有价值的地方。
设计优先的思维方式在纸面上很棒，但是当涉及到实际实施该过程时，公司会面临真正的障碍。根据您的经验，您认为实施设计优先的最大挑战是什么？
这需要大量的工作！我们有一个客户，它工作得非常出色，那是 一些团队之间已经存在牢固的、预先存在的关系。他们在业务目标上非常一致。在这种情况下，我们都与这个北极星保持一致。因此，不仅用户界面团队和中间件团队或 API 团队正在构建共享的 API 合同，而且他们还将共享的北极星目标视为一项业务，他们都在为相同的目标而努力。如果您想考虑相反的情况，那就是人们可能过于孤立的情况。
有些组织，成功就是完成待办事项列表。并且真正地从一些日常工作中抬起头来，记住成功是交付业务价值和客户价值。
我认为，当人们真正围绕他们的北极星保持一致时，并且他们将合同优先的方法视为帮助实现这一目标、促进协调和高质量产品的工具时，您就会看到这种方法的成功。
我知道在上次会议上您谈到了一个客户的用例。您能再详细介绍一下吗？
在那个例子中，我谈到了并行开发，用户界面与模拟的 API 同时进行，而后端也在构建中。各个团队之间有很大的信任，相信他们最终会协同工作并确保一切正确。当人们去了解客户，然后以 MVP 的形式构建整个系统时，会取得更多成功。我认为这是从 API 发布角度来看更常见的用例。
好的，Chris，这真是太棒了。非常感谢您抽出时间分享这些经验！
感谢您的阅读！正在寻找更多 API 资源？订阅 Swagger 新闻通讯。您将每月收到一封包含我们最佳 API 文章、培训、教程等内容的电子邮件。订阅