如今，软件开发围绕 API 构建。开发人员无需将供应商的产品嵌入到他们的应用程序中，而是可以调用 API 来使用供应商的服务。开发人员不需要知道后端是什么在响应他们的调用；他们只需要知道供应商的 API 对他们的代码有什么期望，以及他们可以期望从 API 接收到什么。从很多意义上来说，这都非常非亲密。
这与许多企业应用层产品的商业开源策略背后的传统开放核心模式相反。在开放核心模式中，产品的核心是开源的，而在企业版中，供应商提供并支持专有增强功能。使用 API 方法，产品的核心通常在云中不可见，进出产品的唯一途径是通过 API。
由于 API 的存在，我们看到企业版的差异化、增强功能和价值正在通过工具、小部件和组件迁移到边界。这些可以是闭源和/或开源的，但我们应该看到边界上出现更多开源，因为许多供应商可以通过支持其核心并对 API 调用或事务收费来赚钱。这方面的两个最佳例子是 Twilio 和 Stripe。
这就像家庭装修项目
理解这种情况的一个简单方法是将其与家庭装修项目进行比较。如果您想在现有房屋中增加一个新的浴室，您通常需要聘请一名水管工和一名总承包商。水管工带来管道并“粗略地安装”它们。然后，承包商围绕这些基本服务构建浴室。
大多数人通常不关心甚至不想知道这些管道来自哪里或如何连接到一般的管道系统。我们只知道我们的输入值是什么（是的，你猜对了）以及我们的输出值是什么样的（干净的水）。我们知道这些需要工作，并且要工作良好。我们有一个普遍接受的服务级别协议 (SLA)，这是关于管道应该如何工作的性能期望。如果我们冲马桶，所有东西都应该消失在我们的管道（API）中。当我们打开水龙头时，饮用水需要以一定的压力（另一个 API 性能 SLA）流出。
这里的重点是，我们唯一需要的信息是 API（管道）的性能如何。这种性能期望就是 SLA。如果您正在设计浴室，您将花时间考虑您想购买的水槽的风格、您想安装的瓷砖类型以及新浴室的整体布局。这种“外观和感觉”为我们的家增添了价值。我们仍然需要支付水管工的费用，但每次进行浴室或厨房装修项目时都重新发明整个房子的管道系统将是疯狂的。这里的创新已经从核心转移到边界。
这正是 API 兴起时正在发生的事情。开发人员意识到，从供应商那里获取高性能 API 可以让他们专注于自己的增值服务。
经典的开放核心应用程序
让我们看一些使用开放核心模型的经典开源企业软件示例。
- Sugar: Sugar CRM 向客户和合作伙伴提供其源代码。Sugar 的企业版添加了特定的企业级功能，例如增强的报告、更好的工作流程以及其他企业特定的功能和附加组件。
- JasperSoft: JasperSoft 提供开源商业智能报告。早在 2007 年，其社区中就注册了 超过 30,000 名开发人员。Jasper 提供 SDK 和 RESTful API 以与其产品交互。
- Odoo: Odoo 的开源企业资源规划 (ERP) 应用程序已成为专有软件非常流行的替代方案。围绕其开放核心，Odoo 及其合作伙伴渠道添加了数百个不同的付费模块，这些模块扩展了开源核心。核心框架包含大约 30 个模块，社区创建了数千个模块。其中一些是免费的，但许多其他模块是付费的和闭源的。
- ProcessMaker: ProcessMaker 提供开源业务流程管理 (BPM) 和工作流软件。开发人员可以使用 JavaScript 和 PHP 增强开源版本。ProcessMaker 提供一系列企业插件，包括高级 Active Directory 集成、仪表板和增强的开发人员工具。
许多采用开放核心模型的软件公司都是在最初的开源项目获得显著关注（即数百万次下载）后才这样做的，因此他们成立了一家公司来支持开源代码。渐渐地，这些公司基于开源开发了扩展和订阅。随着云和软件即服务模式在 2000 年代初期和中期变得更加突出，这些公司通常开发基于开源核心的云版本，以进一步区分其产品与开源版本。
也许开源许可证和通过 SourceForge 等下载站点实现的无摩擦分发模式是许多开源产品快速采用的两个最大驱动因素。
发生了什么变化
这种商业开源模式在 1990 年代末和 2000 年代初变得普遍。然而，一场变革正在席卷整个行业：API 的兴起。API 变得越来越重要，原因如下：
- 构建更具可扩展性软件的需求
- 构建更具连接性软件的需求
- 加速创新步伐的需求
- 应对日益增长的复杂性的需求
软件更加复杂，必须连接到更多类型的应用程序，并且必须扩展以处理更大的需求（数量级）。将这三个因素结合起来，您很快就会意识到为什么 API 如此重要。开发人员不能再开发一个单体代码库，并允许其他应用程序以他们想要的任何方式连接到它，并且期望维护软件并确保其在规模上运行良好。API 是两个或多个服务相互交互的清晰且明确声明的方式。通过了解另一个软件期望如何与我的软件一起工作，我可以保持其质量并根据这种期望对其进行判断，即使我的软件不断增长和发展。
基于 API 的商业模式
一些公司已经适应了基于 API 的商业模式。以下是一些例子：
- Twilio: Twilio 提供与通信相关的 API，以支持消息传递、语音和视频。Twilio 的市场提供通过其 API 与 Twilio 集成的第三方附加组件。附加组件构建者利用 Twilio 提供的内容，并使用来自其自身来源的信息对其进行增强；然后，他们的产品作为 API 发布在市场上。
- Stripe: Stripe 的支付处理平台提供用于提交支付的 RESTful API，每年处理数十亿美元的支付。第三方扩展通过为用户的 Stripe 帐户发出 API 请求来提供其他功能。还有第三方库来支持开发以及使 Stripe 与其他产品一起工作的插件。
- Factual: Factual 为移动广告和其他移动应用程序提供基于位置的数据。它提供了一组 API，开发人员可以使用这些 API 构建与 Factual 产品产品集成的扩展。Factual 的某些位置数据通过下载许可证提供给合作伙伴。
- ProcessMaker I/O: ProcessMaker I/O 提供工作流即云微服务。企业 ISV 可以使用 ProcessMaker API 将企业工作流功能添加到其产品堆栈中。工作流 API 可以连接到任何后端，并且可以扩展到每秒数百万次事务。开发人员可以使用 Java、Python、JavaScript、PHP 或其他语言的 SDK 连接到 API。
- Form I/O: Form.io 提供了一个强大的 API 来管理 Web 表单。这些 Web 表单可以在任何类型的无服务器架构中填充数据源。
API 模型的优势
API 模型为开发人员带来了真正的好处。开源和开放核心意味着不断的变化，这会产生（无论是否经过测试）来自意外副作用的持续风险。通过忽略产品的内部核心而支持 API 模型，开发人员可以专注于使用提供的功能，这些功能提供可靠的行为契约。这使得应用程序边界上的创新更快（而且更多！），而不是在核心上缓慢地修修补补，在核心上，您需要对项目有更深入的了解才能为创新做出贡献。
由于 API 可以提供与不同后端系统相同的功能，因此 API 方法在长期内提供了对供应商支持的应用程序的访问，同时降低了供应商锁定的风险。当然，在短期内，连接到供应商的 API 意味着您将依赖于该 API。如果它出现故障，您的应用程序必须弄清楚如何处理它。但是，始终无法满足其 SLA 的 API 提供商将被更可靠的提供商所取代。竞争对手相对容易复制 API，这为开发人员提供了在必要时可以更换 API 的保障。
开发人员可以独立于后端测试 API 的功能，并专注于将这些专门的微服务组合成他们需要创建的更大的应用程序，从而支持他们的业务用户。他们可以专注于他们的核心竞争力——专业的业务知识，而不是将应用程序组合在一起的基础架构。更多地关注业务知识意味着最终产品更符合业务需求。
小型供应商可以发挥重要作用
考虑到 API 是应用程序的新管道（因此也是互联网的新管道），很难想象小型供应商可以发挥作用。然而，他们绝对可以。API 服务正在以惊人的速度 快速增长；它们是长尾创新的真正新驱动力。原因是 API 可以公开真正的微服务。然后，开发人员将这些微服务组合成有意义的应用程序。我预计，在 API 大规模激增几年后，我们可能会开始看到 API 合并。但在那之前，我们不会看到这个故事上演；在此之前，小型参与者在 API 经济中发挥着重要作用。
评论已关闭。