API 管理提供商 aapi 成为 OpenAPI Initiative 的第 30 个成员，这与他们于 11 月 28 日宣布的 API 门户首次亮相相吻合。
“API 正在重塑数字格局，而 OAI 正在通过 API 语言的标准化来推动这一转型，”aapi 首席技术官 Timothy Arvanites 表示。“简化系统的连接性，OpenAPI 规范是 aapi 平台互操作性和简单性的基础。我们自豪地支持开源、Linux 基金会，特别是 OAI，并期待一个 API 易于使用的世界。”
aapi 托管了一个包含超过 3000 个 OpenAPI/Swagger 文件的开放库，其平台旨在通过降低成本、复杂性和 API 学习曲线来简化 API 开发和管理流程。aapi 由 Craig Lund、Timothy Arvanites 和 Robert Phillips 创立。Lund 担任董事长兼首席执行官，而 Arvanites 担任首席技术官。
OpenAPI Initiative 很高兴欢迎 API Fortress，一个自动化 API 测试和监控平台，成为加入 OAI 的最新公司。
“验证 API 质量的一个主要部分是测试，”API Fortress 首席执行官兼联合创始人 Patrick Poulin 分享道，“并且这一步可以通过强大的规范文件格式实现几乎完全自动化。我们很高兴能够直接为 OpenAPI 规范做出贡献，并继续推动 API 驱动的经济发展。”
API Fortress 成立于 2014 年，专注于使 API 测试和监控更加容易。在不降低细节水平的情况下实现这一点很棘手，但有一个灵丹妙药——自动化。使用 OAS 文件，该平台可以将构建详细测试的工作量减少 90%。通过加入董事会，我们希望能够参与到将这一比例提高到每个平台 99% 的过程中。
“值得庆幸的是，严格的单元测试现在已成为开发的积极组成部分。但是，API 的功能集成测试往往会被拖延，”首席技术官 Simone Pezzano 说道。“它总是列在下一季度的计划中，因为要实现完全覆盖所付出的努力是巨大的。这就是我们一直在努力解决的问题，而像 OAS 这样的规范格式是我们能够如此接近完全自动化的原因。”
API Strategy & Practice 大会 即将举行——它将于 10 月 31 日至 11 月 2 日在波特兰举行。我很高兴能参加另一个 API Strategy 大会，我上次参加是在 2015 年的奥斯汀。这次，我将发表演讲！
简单介绍一下我自己——我叫 Sai Vennam，是 IBM 的开发者布道师。我非常喜欢 Node.js，但也经常使用 Java 和 Go。我喜欢谈论我热衷的技术；这尤其包括 API。
如果您参加了会议，请务必查看我在周三关于“为现代应用程序架构构建无服务器 API”的演讲。在现代软件开发时代，企业正在使用最新的尖端技术，如无服务器函数。但是，他们仍然必须支持遗留系统和软件。我将讨论从这些需求中产生的混合应用程序架构，以及无服务器 API 如何融入其中。
无服务器正在迅速获得关注，IBM 处于这一采用的最前沿。我们已经完全在开源中开发了我们的无服务器功能，作为一个 Apache 项目——OpenWhisk。您还可以利用 IBM Cloud Functions 上的功能。
除了会议之外，我还将与才华横溢的 Erin McKean 和其他 IBM 同事一起在展位上与您讨论您最新的 API 项目！
您知道 IBM 是 OpenAPI Initiative 的创始成员吗？详细了解最新的 OpenAPI 规范 v3.0.0 版本。
我们希望在波特兰见到您！请务必来 IBM 展位参观。
详细了解 IBM Cloud：https://www.ibm.com/cloud-computing/bluemix/。
OpenAPI Initiative (OAI) 项目很高兴地宣布 SAP 已加入成为我们的最新成员。OAI 社区致力于为开发 API 的互操作性建立一个开源基础。SAP 与 28 个现有成员一起，推动了一种供应商中立的描述格式。OAI 由 Linux 基金会托管，该基金会是一个非盈利组织，致力于推动专业开源管理，以实现大规模协作。
“全球 500 强公司（如 SAP、IBM 和 Google）能够与 SmartBear 等工具提供商以及 Capital One 等最终用户一起参与 OpenAPI 规范的协作，这证明了 API 社区的共同愿景和开源的有效性，”OAI 项目主席兼 SmartBear 首席技术官 Ole Lensmar 表示。
OAI 于 2015 年启动，旨在标准化 API 的描述方式。最近发布的 OpenAPI 规范 v3 定义了 RESTful API 的接口，以一种易于被机器和人类发现和理解的格式来描述资源和操作。有关该项目和规范的更多信息，请访问 https://www.openapis.org.cn/。
“SAP 致力于为客户提供开放性和选择，”SAP 首席技术官兼 SAP 云平台总裁 Björn Goerke 表示。“SAP 为我们的企业 API 使用机器可读的 OpenAPI 规范。我们相信这将促进以我们的 SAP 云平台为基础的生态系统驱动的创新。”
SAP 继续履行其对开源社区的承诺，此前已加入转型性的 Linux 基金会项目，例如 Cloud Foundry、Hyperledger 和 Node.js 基金会。
我们作为开发者，被强大的、令人惊叹的 API 所包围。仅仅找到时间来集成这些有趣的服务以增强我们的产品可能是一项艰巨的任务，仅仅因为时间是我们作为开发者最稀缺的资源。
API 集成是开发人员经常遇到的一个难题，因为我们经常感觉自己像沮丧的管道工，试图连接不同尺寸和材质的管道，被迫一遍又一遍地创建自定义适配器和连接点。您一定知道这种感觉，对吧？
我们已经生活在一个快节奏的时代，API 经济推动了大部分的技术创新。亚马逊、PayPal、Stripe、Heroku 和 Google Maps 等平台都是各自市场上成功的平台和产品的良好例子，它们在自身周围创建了生态系统。如果您拥有生态系统，您就赢得了比赛。API 有故事要讲：良好的 API——易于第三方使用——可以帮助进一步推广。我们作为 API 使用者，在很多情况下决定哪些 API 会成功，哪些 API 不会再被使用。
在这种快速创新的背景下，API 发现和轻松集成对于城镇上的每一项新服务都至关重要。OpenAPI 规范在这一领域可以提供最大的帮助。
OpenAPI 规范为描述基于资源和 HTTP 的互操作 REST API 提供了一个可靠的标准。此描述对两种类型的受众有用：人类和机器。
根据我的经验，在您的 API 项目中使用 OpenAPI 规范有三种主要的用例：遗留 API、契约优先驱动和服务器优先驱动。让我们逐一审查它们。
第一种场景涵盖已经投入生产的服务和 API。添加 OpenAPI 文档将以标准化方式正式捕获 API 的签名。因此，使用者可以将此契约用作文档，以便轻松集成您的 API。
只要您使用 HTTP 或 HTTPS 以及 JSON 或 XML 编码，无论您选择哪种语言或框架进行实现都无关紧要：您都拥有一个可互操作的 API，等待着被世界发现。
这里最令人惊讶的事情是：**您无需更改正在运行的 API 或服务的一点**。OpenAPI 规范提供的元数据是一个存储在自包含文件（YAML 或 JSON）中的契约，您可以脱机（作为文件）共享或发布在任何 Web 服务器上。
添加契约不会更改您的遗留实现的一点，但会帮助那里的开发人员尝试并使用您的 API。
为了加快开发速度，通常会在两个团队（后端和前端）中并行工作。如果他们达成 API 契约，则两者都可以并行构建其内容。前端人员通常会创建和使用契约的模拟，以便能够工作，而不必等待后端准备就绪。
OpenAPI 和相关的工具在此提供此任务的良好工具。OpenAPI 契约可以进行编辑和验证，而无需任何语言或实现假设（使 API 确实非常、非常地可互操作）。
然后，使用 OAS 代码生成工具，两个团队都可以在任何支持的语言或平台上生成服务器端和前端代理的框架。
当主要功能足够清晰以能够提前设计契约时，我推荐这种工作方式。
从长远来看，您将以计划的方式维护和发展契约。因此，从长远来看，这是高质量 API 契约的推荐方法。
注意：为了在新版本出现时不破坏旧客户端，清晰的版本控制策略非常重要。
在其他类型的项目中，开发人员可以选择直接在其喜欢的语言和平台上构建其 API，并在稍后作为运行实现的直接结果导出 API 契约。OpenAPI 规范也支持此场景。使用针对目标语言的特定库。使用反射技术和元数据来发现服务、类型、参数，直接检查源代码以自动生成符合 OAS 规范的规范。
这种方法有一些优点
该方法的主要缺点
注意：当需求和设计快速变化，并且您的团队正在迭代以找到正确的契约设计时，我建议使用服务器优先方法。由于尚未投入生产，这将减轻破坏客户端的问题。无论如何，在启动最终的 API 契约之前，请完整审查您的 API 契约并进行重构以获得更好的用户体验。
OpenAPI 提供了一种描述 API 的可互操作方式
所描述的三种场景提供了适应不同项目需求的灵活性。老实说，我认为这是 OpenAPI 的前身（称为 Swagger）从一开始就做对的主要功能：很好地适应非常不同的开发场景和不同的项目开发阶段。
与管道或电气工程相比，软件工程仍然是一门年轻的学科。我们需要帮助我们处理和自动化重复性任务的标准。因此，我认为无论您是机器还是人类，使用 OpenAPI 规范公开 API 都是一件好事！
如果您喜欢这篇文章并想了解更多信息，请参加我在马德里 11 月 24 日举行的 Codemotion 上的演讲，让我们深入探讨！
关于作者
Pedro J. Molina
Pedro J. Molina 拥有巴伦西亚理工大学计算机科学博士学位。在从事与建模和代码生成相关的不同产品公司工作后，他创办了一家名为 Metadev 的初创公司，专注于微服务和云开发工具。Twitter: @pmolinam
随着最近发布的 OpenAPI 规范 v3，现在是时候暂停一下，思考一下使用 API 契约来描述您的 Web API 的好处了。通过开放且免费访问的、对计算机友好的格式，它为工具、兼容性或团队协作打开了非常重要的视角，并培养了一个富有成果的生态系统。
简而言之，API 契约是真理的源泉。无论您是实现 API 后端的人，还是调用 API 的使用者，都存在这样一个中心契约，各方都可以依靠它，以确保 API 的外观、预期类型的端点、将交换的有效负载或使用的状态代码。
有了中心契约，团队沟通和协作就变得容易了：我见过一些客户，其中一个中央架构团队会定义一个契约，该契约由第三方（外包咨询公司）实施，并且 API 由不同的团队（内部和外部）使用。此处的中心契约旨在促进这些团队之间的工作，以确保契约得到履行。
此外，拥有这样一个对计算机友好的契约对于工具来说非常有用。从契约中，您可以生成各种有用的工件，例如
但是，在工件生成方面要小心。一旦您开始对工具生成的內容进行一些自定义，您可能会在下次重新生成这些工件时面临覆盖这些更改的风险！因此，请注意如何进行自定义以及如何将其与这些生成的工件集成。
InfoQ 最近发布了去年在巴黎举行的 APIDays 会议的视频。我谈到了使用 Cloud Endpoints 在 Google Cloud 平台上扩展基于 OpenAPI 规范的 Web API。
我多次谈论过这个话题，因为 Web API 是我喜欢的主题，在 Nordic APIs、APIDays 或 Devoxx 上都谈过。但很高兴看到 视频在线。因此，让我与视频一起分享幻灯片。
您还可以查看下面嵌入的幻灯片。
在我的演示和演示中，我决定使用 Cloud Endpoints 来管理我的 API，并在 Google Cloud Platform 上托管我的 API 实现的业务逻辑。GCP（简称）为您的项目提供了各种“计算”解决方案
在我的情况下，我使用了使用 Apache Groovy 编程语言实现的容器化 Ratpack 实现来实现我的 API（还有什么？:-)）。因此，我在 Container Engine 上部署了我的应用程序。
我通过 OpenAPI 描述符描述了我的 Web API，并通过 Cloud Endpoints 进行管理。Cloud Endpoints 实际上是 Google 本身用来托管今天开发人员可以使用的所有 API 的底层基础设施（例如 Google Maps API 等）。此架构每天已经处理了数千亿个请求……因此您可以假设它本身肯定具有相当的可扩展性。您可以管理使用 OpenAPI 描述的 API，无论它们是如何实现的（与底层实现完全无关），它可以管理基于 HTTP 的 JSON Web API 以及 gRPC API。
关于 Cloud Endpoints，无论您是将其用于公共/私有/移动/微服务 API，都有三个有趣的关键方面需要了解
Cloud Endpoints 实际上提供了一个开源的“sidecar”容器代理。您的容器化应用程序将与 Extensible Service Proxy 协同工作，并且实际上会被该代理包裹。所有调用实际上都将通过该代理才能到达您的应用程序。有趣的是，并非只有一个代理，而是您的每个应用程序实例都将拥有自己的代理，从而减少了从调用到代理到应用程序中实际代码执行之间的延迟（这两者之间没有网络跳跃，无需像连接到某个较远的中央代理那样，因为这两个容器是放在一起的）。顺便说一下，此代理基于 Nginx。并且该代理容器也可以在其他地方运行，甚至在您自己的基础设施上运行。
总而言之，Cloud Endpoints 负责保护、监控和扩展您的 Web API。在 Google Cloud Platform 上开发、部署和管理您的 API 为您提供了选择：在协议方面，可以选择基于 JSON/HTTP 的 API 或 gRPC，在实现技术方面，您可以选择平台支持的任何您希望使用的语言或框架，使您可以从 PaaS、CaaS 或 IaaS 中进行选择。最后但并非最不重要的是，此解决方案是开放的：基于 OpenAPI 和 gRPC 等开放标准，或通过在 Nginx 之上实现其代理。
使用像 OpenAPI 规范这样的开放格式来描述 API，所有与 API 相关的利益相关者都可以协同合作并获得以下好处。
首先，团队更容易有效地协同工作，因为所有成员都可以依靠 API 描述作为事实，代表 API 应该是什么样子。当一个团队设计契约而另一个团队（可能是外部团队）实现契约时，这一点尤其正确。有一个描述 API 的唯一事实来源，简化了团队之间的沟通。
其次，作为一种对计算机友好且定义明确的格式，可以自动化各种任务，例如生成模拟、客户端库、服务器骨架等等。您还可以使用该规范来检查实现是否符合契约。
最后，通过开放且免费访问的格式，供应商、开源项目和开发人员的生态系统可以协同合作，防止锁定效应，允许 API 开发人员利用通过 OpenAPI 规范可以相互兼容的工具和解决方案。
此次合作使 eBay 开发人员能够更轻松地与我们的 RESTful 公共 API 集成，并在我们的平台上发展他们的买卖体验。
20 多年来，eBay 一直是领先的市场，将购物者与我们平台上超过 11 亿个商品列表中的理想商品连接起来，并为卖家提供发展业务的机会。今天，我自豪地宣布我们加入 OpenAPI Initiative (OAI)。此合作关系将专注于 OpenAPI 规范，使 eBay 开发人员能够更轻松、更快速地与 eBay 的 RESTful 公共 API 集成，因为我们正在发展 eBay 上的买卖体验。此机会利用技术使我们的开发者生态系统更容易创建新的 eBay 体验。
OAI 是 Linux 基金会下的一个开源项目。这些软件项目由独立资金资助，旨在利用跨行业和生态系统的协作开发的力量。OAI 是定义和创建 RESTful API 最受欢迎的开源框架，拥有数万名开发人员使用这些工具。
作为 OAI 的成员，我们正在继续利用我们的开发者生态系统并发展 eBay 的 API，通过扩大我们的开发者社区并鼓励构建，从而创建一个更集成的平台，并在 eBay 上提供无缝的购物和销售体验。今年早些时候，我们在全球举办了七场开发者活动，启动了 eBay Connect，向外部开发者提供我们平台的见解并鼓励他们进行创新。去年， eBay 开发者计划 改进了我们的 API 平台，推出了 13 个新的基于标准的 API。
此合作关系和我们的新 API 使我们的开发人员和卖家能够更轻松地快速与 eBay 集成并加入所有库存，这是我们承诺为我们的卖家和开发者合作伙伴提供最强大的电子商务平台的一部分，以便他们能够构建复杂的集成来管理 eBay 上所有端到端的销售运营，并轻松扩展其业务。
OpenAPI Initiative (OAI) 是一个 Linux 基金会项目，旨在推进 API 技术，它宣布发布 OpenAPI 规范 3.0.0 版本。OAI 为开发 API 和其他技术的互操作性奠定了基础。
OpenAPI 规范 (OAS) v3 版本是来自多个行业（如支付和银行、云计算、物联网以及构建 API 解决方案的供应商）的资深 API 开发人员和架构师近两年协作的成果。在 OAI 的指导下，这种协作提供了一种统一行业如何定义和描述 API 的通用方法——这些服务是当今互联世界中应用程序相互通信的基础。OpenAPI 规范定义了 RESTful API 的接口，以一种易于被机器和人类发现和理解的格式描述资源和操作。
“第三代格式的发布是我们社区的一个重要里程碑，”SmartBear Software 首席技术官兼 OAI 董事会主席 Ole Lensmar 表示。“所做的更新完全以用户和使用为导向，这在规范的成功中发挥着巨大作用。此版本最强大的功能之一是其推动整个 API 生命周期的能力。”
新版本 3 中的主要改进包括支持描述回调、表达操作之间关系的链接、Webhook、增强的示例、改进的参数描述以及更好的多部分文档处理。其他功能增加了对模板化服务器 URL 和语义版本控制的支持。此处提供了详细列表：OpenAPI 规范 v3
“我们很高兴看到通用 OAI 规范的采用和验证在增长，仅在过去 18 个月里，成员公司数量就增长了近 4 倍，并且政府以及医疗保健和金融科技行业的兴趣也在不断增加，”Linux 基金会执行董事 Jim Zemlin 表示。“这种增长证明了社区通过 API 共享数据的开放方式的愿景。”
API 已从开发技术提升为业务驱动力，是技术创新和现代化的必要条件。根据 ProgrammableWeb 的数据，自 2005 年以来，已发布了近 18,000 个公共 API，仅在 2017 年最后一个季度就增加了近 1,000 个。OpenAPI Initiative 成立于 2015 年，在过去的 18 个月里成员数量已增至 27 个，并且继续加速发展，超越 API 供应商，包括来自银行、医疗保健和全球政府的领导者。
42Crunch
“42Crunch 很荣幸能成为 OpenAPI Initiative 的一部分，”42Crunch 首席创新官 Philippe Leothaud 表示。“OpenAPI 规范是开源的、平台无关的、供应商无关的且可扩展的。利用这种事实上的标准将加速 API 在所有行业领域的采用，尤其是帮助应用程序和设备自动使用 API。”
Hart
“医疗保健领域目前正在经历一场数据革命，API 处于议程的首位，”Hart 总裁 Mohamed Alkady 表示。“通过就通用 API 结构达成一致，使任何人都可以快速帮助构建这个未来，而无需每次都重新学习新的命名法。随着 OAS3 的发布，我们正朝着更完善的结构迈进，该结构可以更广泛地使用和部署。我们相信 OpenAPI Initiative 和联合技术将引领 API 开发的下一代变革，我们很高兴在医疗保健领域推动这一举措向前发展。”
IBM
“OAI 相对快速地发展了此规范，IBM 认知云和 API 经济团队已准备好采用这一新的开放规范，”IBM 数字业务集团开放技术副总裁 Todd Moore 表示。“通过帮助建立 OAI，IBM 与其他理解企业系统稳健、可扩展和安全的 API 是现代数字生态系统基础的公司携手合作。此外，当今的软件开发人员希望使用开放工具来帮助他们快速一致地创建 API 以加速业务转型。我们的客户信赖 IBM 帮助他们管理其整个 API 管理生命周期。”
Kong (Mashape)
“Kong 是世界上最受欢迎的开源 API 网关，我们已经看到了 OpenAPI 规范使用量的惊人增长，”Kong (Mashape) 首席技术官兼联合创始人 Marco Palladino 表示。“API 规范是现代 API 开发、发布和使用工作流程的关键部分——OpenAPI Initiative 一直不懈地将行业领先的 OpenAPI 规范格式推进到其里程碑式的 3.0.0 版本。我们很高兴继续为 OAS 周围的工具生态系统做出贡献。”
Microsoft
“Microsoft 祝贺 OpenAPI Initiative 及其开发人员发布 OpenAPI 规范的第三版，”Azure 开发者体验首席项目经理 Kamaljit Bath 表示。“我们在整个公司中使用 OpenAPI，包括：用于描述 Azure API 并使用 AutoRest 工具生成客户端库，用于描述与 Azure LogicApps/Microsoft Flow 集成的 150 多项服务，用于客户描述他们引入 Azure API Management 服务的 API，以及用于描述我们生成文档的 API 的文档，这些文档托管在 https://docs.microsoft.com/ 和 https://apidocs.microsoft.com/ 上。我们期待最新版本及其带来的易于创作、维护和使用 OpenAPI 描述的改进。”
MuleSoft
“OpenAPI 规范 (OAS) 的新版本包含了更全面地描述 API 的重要进步，”MuleSoft 首席技术官 Uri Sarid 表示。“API 规范对于实现稳健、高效且快速增长的业务功能市场至关重要。反过来，这些市场是企业、政府和整个行业的数字化转型的核心。OAS 版本 3 提供了一种描述 API 的广泛格式，RAML 提供了一种强大的 API 建模格式，API 建模框架利用两者提供可重用性和一致性以及构建 API 工具的通用 SDK。我们期待继续投资于这些领域，并推进 OAI 标准，为 API 生态系统创造价值。”
Red Hat
“Red Hat 坚定地支持开放标准和开源，”Red Hat Inc. API 管理高级总监兼负责人 Steven Willmott 表示。“OpenAPI Initiative 的进步以及此版本展示了社区的力量，我们很高兴看到行业围绕强大的通用标准形成共识。”
SmartBear
“SmartBear 是开源社区的坚定支持者，在 2015 年将原始的 Swagger 规范捐赠给了 OAI。规范的演变表明，将来自各行业的合作者聚集在一起以开放透明的方式发展规范以满足全球 API 开发人员和消费者的需求的力量，”Swagger 开发者布道师 Ron Ratovsky 表示。“SmartBear 致力于通过我们的开源 Swagger 工具和我们的集成平台 SwaggerHub 来支持 OAS 3.0。”
Tyk Technologies
“越来越多的客户正在采用 OpenAPI 规范作为事实上的 API 描述格式，”Tyk Technologies 首席执行官兼创始人 Martin Buhr 表示。“作为领先的开源 API 管理平台，Tyk 致力于开源和开放标准，我们很高兴能参与 OAS v3.0 规范的发布。”
OAI 的当前成员包括：42Crunch、Adobe Systems, Inc.、API Evangelist、Atlassian、CA Incorporated、Capital One、Cloud Elements、Finxact, LLC、Google, Inc.、Hart、IBM、Intento, Inc.、ISA Research Group、Mashape Inc.、Microsoft Corporation、MuleSoft、Oracle Apiary、Red Hat、RepreZen、Restlet, Inc.、Salesforce、Samsung ARTIK Cloud、SmartBear Software、Software AG、StopLight 和 Tyk。
OpenAPI 是 Swagger 规范的演进版本，Swagger 规范于 2015 年由 SmartBear 捐赠给 Linux 基金会。要了解更多关于 OpenAPI 规范的信息，并了解会员资格和贡献，请访问：https://www.openapis.org.cn/
OpenAPI 规范 v3
在 Twitter 上关注 OAI @OpenApiSpec 或在 GitHub 上加入讨论
关于 OpenAPI Initiative
OpenAPI Initiative (OAI) 由一群具有前瞻性的行业专家创建，他们认识到标准化 REST API 描述方式的巨大价值。作为 Linux 基金会下的一个开放治理结构，OAI 专注于创建、发展和推广一种供应商中立的描述格式。访问 https://www.openapis.org.cn/ 获取更多信息。
###
Linux 基金会已注册商标并使用商标。有关 Linux 基金会商标列表，请参阅其商标使用页面：https://www.linuxfoundation.org/trademark-usage。Linux 是 Linus Torvalds 的注册商标。
通过这篇博文，我们开启了为期两周的 OpenAPI 规范 v3 最后一次征求意见期。OpenAPI 规范 v3。
正如上个月提到的，OpenAPI 规范 v3 现已进入最后一次征求意见期。您可以在以下网址找到 OpenAPI 规范 v3 的最新候选版本： https://github.com/OAI/OpenAPI-Specification/releases
在 6 月 16 日星期五的会议上，技术开发者社区 (TDC) 确认了以下日期
无论您自 v2.0 以来是否未查看过规范，或者是否将 v3.0.0-rc1 的磨损副本放在键盘旁边，这都是您影响规范草案的最佳机会，在它发布之前。
以下是一些提供反馈的方式
该OpenAPI 规范 v3处于“候选版本”阶段。在一些领域，特别需要您的意见，例如示例的清晰度和功能的描述。欢迎您提出新功能或对现有功能进行重大更改的建议，但很有可能仅在未来的版本中考虑这些建议。
注意：TDC 成员表示更倾向于 pull request，因为它使意图更加清晰，并且所有更改最终都必须经过此阶段。如果您无法提交 PR，则 issue 是次佳选择。
如果您想全面了解 OpenAPI 规范 v3，请查看
正在播放： Semisonic 的 Closing Time
本周 Finxact 宣布已成为 OpenAPI Initiative 的正式成员。Finxact 与银行业合作开发开放银行 API。
Finxact 基于 OpenAPI 规范 - OAS 开发了一个开放银行 API 及其社区。作为一个虚拟核心，第三方服务和银行现有的系统通过 Finxact 的开放银行 API 连接到 Finxact 的核心处理规则引擎和系统记录。
“OAI 及其不断增长的成员委员会很高兴欢迎 Finxact 加入工作组。Finxact 将成为首家正式拥抱我们工作组开放、透明和互操作性使命的核心银行提供商，”OAI 主席 Ole Lensmar 说。“Finxact 及其合作伙伴正在做出开创性的贡献，这将使银行和金融科技公司能够使用 OpenAPI 规范 (OAS) 作为其交互的推动者，自由且透明地进行互操作。”
阅读完整新闻稿 此处。
