加入 OAI 是我们 Cloud Elements 产品开发战略中不可或缺的一步，我们相信这将进一步增强我们 API 集成平台的简易性，并继续减轻客户将 Cloud Elements 与其他 API 管理平台和 API 网关结合使用的负担。最终，我们相信 OpenAPI Initiative 不仅为我们自己的开发人员节省了大量时间，也为我们的客户的开发人员节省了时间。

根据规范构建 API 是成功的关键。我们的高级平台工程师 Rocky Madden 补充道：“OpenAPI Initiative 不仅承担了 Swagger 规范，而且还在 v3.0 中提升了其水平，改进了人类和机器如何发现和理解 API 的方式。互操作性是 OAI 的核心。当工具和服务能够围绕相同的通用规范构建时，这非常强大，使我们能够创建强大的集成，改进我们与其他 API 的互操作方式，缩短交付时间等等。”

Rocky Madden, Senior Software and DevOps Engineer, Cloud Elements

Rocky Madden，
Cloud Elements 高级软件和 DevOps 工程师

Madden 继续说道：“具体到我们而言，OpenAPI 规范改进了我们自己的平台，并帮助我们快速将新的元素（端点）添加到我们的集成目录中。标准化也使我们能够利用其他也基于 OAI 构建的云服务。我们与亚马逊 AWS 等公司的合作关系将使开发人员能够轻松地将 REST API 发布到此类市场中，这在一定程度上得益于与 OpenAPI Initiative 的合作。”

包括我们在内，有很多公司加入了支持 OpenAPI Initiative 的行动。我们非常高兴成为 OAI 的一部分，并继续创建和发展 API 描述格式。

11月 17

喜欢0

TDC：文档，解释 3.0 规范第 5 部分

作者 Jeff ErnstFriedman 博客

随着 OpenAPI 规范 3.0 版本即将发布候选 Beta 版本，此系列帖子旨在从技术开发人员社区 (TDC) 的角度深入了解正在发生的变化以及如何发生变化。本系列之前的帖子描述了规范下一次演变的背景和基本原理，一些结构性变化，请求参数以及协议和有效负载。

文档

围绕 OpenAPI 规范先前版本发展起来的各种各样的工具表明，这些开发人员可以访问构建这些工具所需的信息。3.0 版本不仅应该延续这种成功，而且随着 TDC 和社区成员参与度的提高，规范应该比以前更易于访问、更清晰、更明确。

通用标记

2.0 规范使用 GitHub 风格的 Markdown (GFM) 来提供服务的丰富文本描述。不幸的是，GFM 本身没有正式规范，并且其某些功能仅适用于托管在 GitHub 上的内容。出于这个原因，OpenAPI 规范 3.0 草案采用了 CommonMark 格式，这将使工具能够在其 Markdown 渲染方面更加一致。CommonMark 大部分与 GFM 兼容，因此此更改对现有文档几乎没有缺点或影响。并且随着 CommonMark 带来的详细规范，更高的精度将减少歧义，并且总体上应该是一项福音。

下一篇文章将讨论社区提出的其他各种未决问题。

——
关于作者
Darrel Miller 是 Microsoft Azure API Management 的高级软件开发工程师。Darrel 是 OpenAPI 规范技术开发人员社区的成员。您可以在 Twitter 或他的博客 Bizcoder 上关注他。

11月 14

喜欢0

TDC：协议和有效负载，解释 3.0 规范第 4 部分

作者 Jeff ErnstFriedman 博客

随着 OpenAPI 规范 3.0 版本即将发布候选 Beta 版本，此系列帖子旨在从技术开发人员社区 (TDC) 的角度深入了解正在发生的变化以及如何发生变化。第一篇帖子描述了规范下一次演变的背景和基本原理，第二篇涵盖了结构性变化，第三篇讨论了请求参数。

协议和有效负载

OpenAPI 规范在描述标准请求/响应 HTTP API 方面取得了巨大成功。但是，社区中的许多人表示有兴趣描述超出简单 HTTP 模型的分布式 API，例如 WebSockets API、RPC API、超媒体 API 和发布/订阅 API。经过 TDC 的多次讨论，目标是将规范扩展到其中一些新的用例，而不会对现有用例增加明显的复杂性。

回调

Webhooks 利用 HTTP 实现发布/订阅模式，已成为包括 Slack、GitHub 和许多其他流行服务在内的 API 提供商中的一种流行模式。Webhooks 使用简单，并且可以很好地融入现有的基于 HTTP 的 API 风格。但是，OpenAPI 规范的一个批评意见是它无法描述出站 HTTP 请求及其预期的响应。新的callback 对象使得这成为可能。一个callback 对象可以附加到订阅操作，以描述订阅者可能期望的出站操作。

链接

许多描述超媒体 API 的方法已被提议到 GitHub 上的 OpenAPI 存储库。一个主要问题是，超媒体 API 中资源的静态描述与超媒体 API 的运行时/发现哲学优势相违背。尽管如此，能够描述 API 中资源之间的静态关系仍然具有一定的好处。为此，3.0 草案规范引入了links 对象来描述根据从初始资源检索到的信息可以访问哪些新资源。这并不一定是超媒体驱动的，因为新资源的 URL 尚未嵌入到返回的有效负载中，但它们是根据 OpenAPI 规范中定义的规则构建的。引入了一种新的表达式语法，允许将来自响应的信息与链接操作中的参数相关联。

Path Item Link Object

资源之间链接的静态描述应该允许生成更有用的文档和客户端库，这些库可以封装从一个资源遍历到另一个资源的过程。这可以允许客户端库减少客户端应用程序和服务器定义的资源层次结构之间的耦合。

JSON Schema

许多请求要求扩展 OpenAPI 规范允许的 JSON Schema 子集，以包含 JSON Schema 的更复杂功能。在 2.0 规范过程中，围绕代码生成的潜在工具复杂性促使排除了 anyOf 和 oneOf。但是，许多用户已请求放宽该约束，即使这会影响对这些功能的工具支持。这是规范设计中的一大挑战，在做出这样的选择时，永远都不容易知道是提供人们可能伤到自己的锋利工具更好，还是依靠经验说“不”，这项责任的负担太大了。虽然 OpenAPI 2.0 采用了更保守的方法，但用户群已变得更有经验，因此一些限制正在被解除，用户将不得不做出明智的选择。

替代 Schema

随着对非 JSON 媒体类型支持的改进，仅使用 JSON Schema 来描述有效负载的局限性变得越来越难以维持。TDC 目前正在探索如何启用描述非 JSON 有效负载的 Schema 的选项。如果克服了这一挑战，则可能可以完全删除表单参数类型，并启用对像 gRPC 这样的使用 protobuf 和 protobuf schema 的协议的支持。

下一篇文章将讨论一些计划对文档进行的改进。

11月 01

喜欢0

OpenAPI 规范在 APISTRAT 2016 上

作者 Jeff ErnstFriedman 博客

OpenAPI Initiative (OAI) 致力于创建、发展和推广基于 Swagger 规范的供应商中立的 API 描述格式。作为 Linux 基金会下的开源项目，OAI 致力于开发和推广 OpenAPI 规范以供所有人使用。我们欢迎来自成员和非成员的贡献。

您和您的组织可以做很多事情来帮助社区。

利用规范：使用 OpenAPI 规范无需支付任何费用或满足任何会员资格要求：GitHub | OpenAPI 规范
开发规范：欢迎社区所有成员参与关于如何发展规范的对话。找到与您的项目相关的元问题之一。如果您没有看到此处，请记录一个新问题。
分享您如何使用规范。
- 关注我们的 Twitter：@OpenApiSpec
- 加入我们的 LinkedIn 群组：OpenAPI 规范
- 参加您所在地区的聚会，或提供在聚会上进行演示。
- 当然，您也可以在自己的博客上分享。
如果您希望直接支持该项目，请考虑让您的公司加入 OAI 成为成员。填写此表格以了解更多信息。项目章程在此。

不确定如何开始？请阅读如何参与此处。

在 APISTRAT 2016 上了解更多信息

11月3日

API 设计与治理 | 上午 11:00 – 下午 12:30
Matthew Reinbold，Capital One DevExchange API 卓越中心负责人
当一家公司决定将所有内容都变成 API 时会发生什么？组织可能会迅速效仿 Netflix 和 Amazon，追求微服务和面向服务的架构 (SOA)。但如果没有应用 Conway 定律，任何治理工作（以及 API 程序）都将达不到预期。Matthew 在多个企业公司中建立和发展 API 治理程序方面发挥了重要作用。在本次演讲中，他将讨论有效的 API 治理以及实现它的挑战。

微服务：gRPC 或 REST？为什么两者兼而有之？ | 上午 11:00 – 下午 12:30
Sandeep Dinesh，Google Cloud 开发者布道师
在本次演讲中，Google 的 Sandeep Dinesh 将向您展示如何构建一个 gRPC 端点，该端点可以智能地通过 HTTP/2 提供 gRPC，同时在同一端口上通过 HTTP/1.1 提供 JSON/REST！然后，他将介绍一些基准测试和最佳实践，用于以可扩展的方式部署这些微服务。在此处阅读更多信息

超媒体

超媒体与图：最佳拍档还是下一个 API 争夺战场？ | 下午 1:30 – 下午 3:00
Gareth Jones，微软
我们都想知道今年是否是超媒体成为主流的一年？但随之而来的是一个新的挑战者：预定义广泛关系网络的图形形状 API 承诺了一些超媒体 API 的优势，但提供了一种更熟悉的编程模型。在超媒体甚至没有机会之前，图是否会将其推开，或者两种风格是否都能很好地发挥作用？这种趋势是 HATEOS 涅槃的障碍还是垫脚石？
我将挑战听众考虑结合这两种方法，为超媒体的主流使用打开大门，用动态数据和行为丰富固定的图形。易变的数据和逻辑可以使用超媒体，而更基础的数据可以使用图形方法。通过这种方式，我们可以为我们的应用程序增加价值和深度，而无需我们通常期望从过渡到超媒体中获得的彻底重写。在此处阅读更多信息

企业
为遗留 SOAP 服务注入新的活力 | 下午 3:05 – 下午 4:35

Darrel Miller，微软软件开发人员
现实情况是 SOAP 服务不再酷了。如今的开发人员希望与标有 REST 的 API 集成。他们想要描述性 URL、JSON 有效负载和熟悉的 HTTP 状态代码。但是，许多企业花了 10 年时间构建 SOAP 服务，并且其中许多服务今天仍在正常运行。重写它们将是一项巨大的工作，而收益却微乎其微。好消息是，无需重写即可为开发人员提供他们想要的东西。您可以利用 HTTP 的分层架构在 SOAP 服务前面放置一个外观，重用所有现有代码，为您的服务注入新的活力，并仍然支持愉快地发送 SOAP 消息的现有客户端应用程序。本次演讲将探讨将本机 HTTP 请求转换为 SOAP 消息并转换回本机 HTTP 响应的过程。我们将讨论外观过程的哪些部分可以自动化，哪些部分需要设计决策。最后，我们将探讨使用这种新型 API 可以获得哪些功能以及会失去哪些功能，以便您可以对 SOAP 服务的未来做出明智的决策。

大图景中的大问题 | 下午 3:05 – 下午 4:35
Amber Fallon，SmartBear 软件
API 规模很大。比我们许多人（甚至行业中的我们）意识到的更大——事实上，公共 API 的总数从 2012 年的不到 7,500 个激增到 2015 年的超过 15,000 个。大型公司拥有更大的 API 结构，比以往任何时候都拥有更多的依赖项和集成，而且这个数字还在增长。整个商业模式已经围绕着一些行业巨头提供的 API 形成。想象一下，像 Uber 或 Waze 这样的应用程序巨头在没有 Google 地图技术的情况下运行，或者 Netflix 与支持其视频流的底层应用程序之间的重要关系——这些应用程序绝对依赖于其底层 API。而且，每天都会出现依赖公共 API 的新应用程序。
随着规模的扩大，随之而来的是一些挑战，例如以促进依赖 API 增长、扩展、维护 SLA 以及允许用户创建应用程序的多功能性的方式管理您的公共 API；您的 API 可能以您从未设想的方式使用。在本届会议中，我将解决诸如大规模沙箱、帮助最终用户集成以及管理大型 API 可能遇到的无限数量的依赖项等挑战。

您可以降低到多低？使用 AWS Lambda、API Gateway、Elastic Beanstalk 和 3scale（别忘了 Swagger！）降低成本和开发时间 | 上午 9:05 – 上午 9:30
Erin McKean，Wordnik 创始人
超过 18,000 名开发人员拥有 Wordnik API 的密钥，他们使用这些密钥构建从教育科技应用程序到文字游戏到 Twitter 机器人的各种内容！我们的原始架构自 2010 年以来已处理了超过 20 亿次调用，并且在很大程度上一直是一项免费服务。当 Wordnik 于 2014 年底重新启动为非营利组织时，我们意识到我们必须将其 API 货币化以创建一个可持续发展的未来发展基础，并且为了货币化，我们需要降低运营成本并引入新功能——我们的先前架构都没有使这些变得简单。进入 AWS Lambda+API Gateway！通过将我们当前的 API 分解成微小的函数，我们可以利用当前的微服务热潮，而无需担心操作方面的麻烦。并且通过使用 Elastic Beanstalk 和 3Scale 来管理反向代理，处理旧 API 调用和新 API 调用之间的路由以及管理计费也变得容易得多。在顶部添加一个漂亮的 Swagger 接口，就可以开始了……更快、更便宜！

11月4日

测试和监控
使用 Cucumber 测试您的 API | 上午 11:15 – 下午 12:45
Ole Lensmar，SmartBear 软件首席技术官

基于Cucumber的BDD（行为驱动开发）正日益流行，因为它允许使用自定义领域特定语言来表达需求，这些需求可以作为测试来验证实际的实现。特别是API似乎可以从这种方法中获益良多，因为它们本质上往往是技术的；看起来，正确执行的Cucumber实现应该允许越来越多的非技术利益相关者参与定义API的行为和功能的需求。但是，为了描述像API这样本质上是技术性的东西，Cucumber词汇表可以变得多么“非技术化”？何时使用命令式方法与声明式方法更有意义？如何将简单的语言转换为复杂的负载和验证？随着API复杂性的增加，Cucumber的使用如何扩展？以及像Swagger这样的标准如何使Cucumber测试更加直观？我知道你迫切想知道——所以不要错过这个机会，踏上API Gherkin Nirvana的道路！

金融科技
超越API文档的OpenAPI之旅 | 下午2:00 – 3:30
Arnaud Lauret，AXA银行IT架构师
OpenAPI提供了许多跨越整个API生命周期的可能性，但它被纯粹视为生成API文档的解决方案。本演讲将讲述AXA银行从.doc和.pdf API文档到广泛使用OpenAPI规范（以前称为Swagger）的演变历程。在整个过程中，我们将识别出API定义语言除了简单地生成API文档之外的许多优势，包括设计、测试、文档持续交付、代码生成、模拟和原型设计新想法。

站在巨人的肩膀上：Capital One如何构建其API | 下午2:00 – 3:30
Abdelmonaim Remani，Capital One DevExchange工程技术主管
自从首次引入以来，REST架构风格一直存在着高度模糊性和大量歧义。早期缺乏具体的参考实现导致最流行的Web API确立自身为黄金标准。为了赢得每个Web开发人员的心和思想，领先的技术公司投入大量资金构建RESTful API，并投入了巨大资源来宣传他们自己的REST风格。Capital One也不例外。对于一家规模如此庞大的金融机构来说，这似乎违反直觉，并且作为受限于过时技术和受法规约束的行业中的参与者，这极具挑战性，但Capital One正全力参与一项公司范围内的计划，以通过内部和面向公众的API公开金融服务，这些API使用最新和最棒的开源技术实现。本次演讲将介绍Capital One如何使用REST，其中风险要高得多，而且风险远不止于为客户提供错误的转向指示。

API的全生命周期工具支持 | 下午2:00 – 3:30
Steven Fonseca，Intuit首席服务架构师
演讲的重点是展示Intuit内部的一个名为API生命周期管理器的工具，这是一个Web应用程序和一组API，使IT组织能够在其整个生命周期中（从构思到退休）高效地生成API。与会者将能够了解Intuit IT如何协调战略性API组合的构建，包括其功能分配和服务所有权、使用当前行业建模语言中找不到的创新进行全面的合同文档、文档生成和交付。API生命周期管理器的示例将在IT如何支持Intuit产品提供愉悦的客户体验的故事背景下展示，尤其是在基于订阅的计费和商务领域。

感谢您

OpenAPI Initiative很荣幸赞助今年在波士顿举行的APISTRAT 2016（11月2日至4日）。加入OAI成员：3Scale、Apiary、Capital One、Cloud Elements、IBM、Intuit、Microsoft和SmartBear，一起讨论API经济。第七届大会将汇聚来自各行各业的人士，从对API感兴趣的人到今天的领导者，共同探讨API领域的机遇和挑战。