高德开放平台显示城市边界_开放核，开放边界和企业软件的未来

高德开放平台显示城市边界

如今，围绕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年代初和中期变得越来越突出，这些公司经常基于开放源代码内核开发云版本，以进一步将其产品与开放源代码版本区分开。

Swift采用许多开源产品的两个最大推动力可能是开源许可证和通过SourceForge等下载站点进行的无摩擦分配模型。

发生了什么变化

这种商业开放源代码模型在1990年代末和2000年代初开始普及。 但是，变化正在席卷整个行业： API的兴起 。 API变得越来越重要的原因有以下几个：

1. 需要构建更多可扩展的软件
2. 需要构建更多的连接软件
3. 需要加快创新步伐
4. 应对日益复杂的需求

软件更加复杂，必须连接到更多类型的应用程序，并且必须进行扩展以处理更大的需求（数量级）。 结合这三个因素，您很快就会意识到API如此重要的原因。 开发人员不能再开发整体代码库，而允许其他应用程序与其连接，但是他们希望并且期望维护该软件并确保其大规模运行。 API是两个或多个服务相互交互的清晰明确的方式。 通过了解其他软件预期如何与我的软件一起使用，即使我的软件不断发展和发展，我也可以维持其质量并根据此期望进行判断。

基于API的业务模型

一些公司已经适应了基于API的业务模型。 这里有几个：

• Twilio： Twilio提供与通信相关的API，以支持消息传递，语音和视频。 Twilio的市场提供通过其API与Twilio集成的第三方加载项。 附加组件构建者可以利用Twilio提供的内容，并使用其自身来源的信息对其进行增强； 然后将其产品作为API在市场上发布。
• Stripe： Stripe的付款处理平台，提供用于提交付款的RESTful API，每年处理数十亿美元的付款。 第三方扩展通过向用户的Stripe帐户发出API请求来提供其他功能。 还有第三方库来支持开发和使Stripe能够与其他产品一起使用的插件。
• 事实： 事实为移动广告和其他移动应用程序提供了基于位置的数据。 它提供了一组API，开发人员可以使用它们来构建与Factual产品产品集成的扩展。 Factual的某些位置数据可通过下载许可证提供给合作伙伴。
• ProcessMaker I / O： ProcessMaker I / O提供了“工作流程即云”微服务。 企业ISV可以使用ProcessMaker API将企业工作流功能添加到其产品堆栈中。 工作流API可以连接到任何后端，并且每秒可以扩展到数百万个事务。 开发人员可以使用Java，Python，JavaScript，PHP或其他语言的SDK来连接到API。
• 表单I / O： Form.io提供了用于管理Web表单的强大API。 这些Web表单可以填充任何类型的无服务器架构中的数据源。

API模型的优势

API模型为开发人员带来了真正的好处。 开源和开放核心意味着存在不断的变化，这些变化会（无论测试如何）产生意料之外的副作用带来的持续风险。 通过忽略支持API模型的产品内核，开发人员可以专注于使用提供可靠行为契约的公开功能。 这样可以在应用程序的外围实现更快的创新（甚至更多！），而不必在核心处进行缓慢的修补，在核心处您需要对项目有更深入的了解才能为创新做出贡献。

由于API可以提供与不同后端系统相同的功能，因此API方法可提供对供应商支持的应用程序的访问，同时可以长期降低供应商锁定的风险。 当然，从短期来看，挂接到供应商的API意味着您将依赖于该API。 如果出现故障，您的应用程序必须弄清楚如何处理它。 但是始终无法满足其SLA的API提供程序将由更可靠的提供程序代替。 竞争对手复制API相对容易，这为开发人员提供了在必要时可以替换API的安全性。

开发人员可以独立于后端测试API的功能，并专注于将这些专用微服务组合到他们需要创建的大型应用程序中，以支持其业务用户。 他们可以专注于自己的核心能力-专业的业务知识-而不是将应用程序整合在一起的基础架构。 更多地关注业务知识意味着最终产品更针对业务需求。

小型提供商在其中扮演着重要角色

考虑到API是应用程序的新领域（因此也是Internet的新领域），很难想到小型提供商会有所作为。 但是他们绝对可以。 API服务正以惊人的速度激增； 它们是长尾创新的真正新动力。 原因是API可以公开真正的微服务。 然后，开发人员将这些微服务融合到有意义的应用程序中。 我希望经过几年的大量API普及后，我们可能会开始看到API整合。 但是，我们不会在短时间内看到这个故事。 在此之前，较小的参与者在API经济中扮演着重要角色。

翻译自: https://opensource.com/article/17/8/open-core-vs-open-perimeter

高德开放平台显示城市边界