跳至主要内容
搜索
类别

博客

9 月 24
喜欢0

OpenAPI 是人！

作者 博客

在 2020 年 API 规范大会上，OpenAPI 社区的有影响力的成员齐聚一堂，讨论了让 OpenAPI Initiative 顺利运行的人员和流程。

不同公司之间的合作是 OpenAPI 社区最显著的方面之一。竞争对手意识到为 API 创建标准化描述的重要性，并团结起来实现共同目标。在最近的一次讨论中，有影响力的社区成员庆祝了 OpenAPI 的成就，并回顾了它的发展历程。

演讲嘉宾包括：

Mitchell 讨论了在她的工作中实施 OpenAPI 描述如何改善了开发人员体验，帮助了内部开发，并使非技术开发人员能够更好地理解内容。她还提供了关于开发人员如何为 OpenAPI 做出贡献的见解。

任何开发人员都可以加入技术开发人员社区，并参与社区。这是一个很好的地方，可以提问和分享知识。另一方面，技术指导委员会 (TSC) 由选出的成员组成，他们做出高级决策以确保 OpenAPI 顺利运行。Gardiner 和 Miller 都是 TSC 的成员，他们讨论了为 OpenAPI 添加新功能的一些困难。

OpenAPI 规范必须满足开发人员的要求，但也必须让新手能够访问。平衡功能和复杂性是一件很微妙的事情，TSC 通常会谨慎地添加不必要的特性。但是，他们会倾听社区的意见，并在对某个特定主题的兴趣不断上升时做出回应。

有关如何为 OpenAPI Initiative 做出贡献的更多信息，请访问 网站！

  • 参与 TSC 每周网络会议
  • 成为 OpenAPI Initiative 的成员
  • 观看 OpenAPI 是人！环节的视频录制
9 月 22
喜欢0

从 0 到 OpenAPI：GitHub 如何描述一个 10 年前的 API

作者 博客

GitHub 最近调整了他们庞大而古老的 API，以符合当前的 OpenAPI 标准。在 API 规范大会上，我们有机会从该项目的领导者那里了解他们是如何完成这一壮举的。

GitHub 最近发布了他们 REST API 的 OpenAPI 描述。现在，使用简单、标准化的 API 调用将项目与 GitHub 数据集成比以往更容易。然而，GitHub 的 API 团队在描述他们的庞大 API 时面临着许多挑战，以使其符合 OpenAPI 规范。在某个时刻，他们的 API 出现了超过 37,000 个错误和 500 个无效运算符！

他们对这些挑战的独特解决方案的激动人心的解释可在 此处 获得。

对 OpenAPI 规范的简要描述

  • “OpenAPI 规范 (OAS) 为 HTTP API 定义了一个标准的、与编程语言无关的接口描述，它允许人和机器在不需要访问源代码、其他文档或检查网络流量的情况下发现和理解服务的 capabilities。”

GitHub 采用 OpenAPI 规范为他们的 API 自动化 SDK 和文档。使用 OpenAPI 描述还有助于确保 API 用户的开发人员体验一致。最后，实施 OpenAPI 描述简化和标准化了系统，使 GitHub 的 API 团队能够专注于项目的其他方面。

GitHub 开源 REST API 可在以下链接获得：

https://github.com/github/rest-api-description

GitHub REST API 文档：

https://githubdocs.cn/en/rest/overview/resources-in-the-rest-api

9 月 01
喜欢0

注册的理由！ASC 2020 主题演讲小组深入探讨现实世界的 API 体验

作者 博客

如今，API 在许多情况下都是必不可少的，但归根结底它们仍然只是接口。那么是什么赋予了 API 意义？API 如何保持可用性和实用性？了解如何在 OpenAPI 的 ASC 2020 中透过接口，从更深入的角度看待 API 产品。

API 规范大会 (ASC) 是 API 从业人员齐聚一堂，讨论 API 技术演变的场所。ASC 包括前沿技术主题演讲和会议，这些主题演讲和会议通过深入的规范和标准讨论来描绘 API 的未来。该活动旨在高度互动，在会议期间提供大量讨论时间。

主题演讲小组：API 产品的规范是什么？

由 Erik Wilde（Axway）主持，加入主题演讲嘉宾 Mike Amundsen（Amundsen.com, Inc.）、Yina Arenas（微软）、Adam DuVander（EveryDeveloper）和 Gail Frederick（Salesforce），他们在 **太平洋时间 9 月 10 日上午 9 点** 讨论 API 产品的规范。了解了解我们为什么要构建这些 API，应该如何帮助我们更好地识别有价值的规范，并为客户提供最大价值。

在此注册

主题演讲主持人 + 演讲嘉宾

**Erik Wilde** 通过帮助公司制定战略和计划来支持他们在数字化转型之旅中取得成功。凭借其计算机科学背景，他专注于技术。然而，凭借其在公司内 API 举措方面的丰富经验，他还专注于业务和组织问题。Erik 是世界各地会议上的常客，定期在各种出版物上发表文章，并且积极参与标准化工作。

**Adam DuVander** 是一位开发者传播者和啦啦队长。他帮助公司通过真实的内容接触和吸引开发者。

他以前曾在一些最好的 API 和开发者公司工作，包括 Zapier 和 SendGrid。许多人仍然可以在 ProgrammableWeb 上找到他的文章，他在那里担任了该有影响力的期刊的第一任编辑。他是一位出版作家和国际演讲者，但他的孩子们仍然没有留下深刻印象。

**Yina Arenas** 领导微软 Graph 的工程工作，微软 Graph 是 Microsoft 365 中数据和智能的门户，也是微软最引人注目的工程项目之一。她在微软的职业生涯中一直在构建平台，使开发人员能够构建访问 Office 和所有微软云服务中的数据和关系的应用程序。她来自哥伦比亚波哥大，并在 2010 年从弗吉尼亚大学获得计算机工程硕士学位后加入微软。她与丈夫和 4 个精力充沛的儿子住在西雅图，并积极参与培养、留住和赋能科技女性的活动。在 Twitter 上关注她：@yina_arenas。

**Mike Amundsen** 是国际知名的作家和演讲者，为世界各地的组织提供网络架构、Web 开发以及技术与社会的交叉领域的咨询服务。他与大小公司合作，帮助他们利用 API、微服务和数字化转型带来的机会。

Amundsen 撰写了大量书籍和论文。他为 O'Reilly 的书籍 “持续 API 管理”（2018 年）做出了贡献。他的 “RESTful Web 客户端” 于 2017 年 2 月由 O'Reilly 出版，他与人合著了 “微服务架构”（2016 年 6 月）。他的最新著作——“设计和构建出色的 API”——为 Pragmatic Publishing 编写，计划于 2020 年 7 月出版。

**Gail Fredrick** 是 Salesforce 的 Salesforce 开发人员体验工程高级副总裁。

在 Salesforce 之前担任的角色包括 eBay 的移动和开发者生态系统副总裁、英特尔开源技术中心的工程总监，英特尔 Linux 的核心。极客天堂。在此之前，他是华盛顿州西雅图市 Medio Systems 的移动软件架构师。Medio 于 2014 年 7 月被诺基亚/HERE 收购。她关于基于标准的移动 Web 开发的论文是 “开始智能手机 Web 开发”，由 Apress 于 2009 年 12 月出版。

8 月 18
喜欢0

OpenAPI 欢迎新成员 APImetrics！

作者 公告，博客

欢迎！

APImetrics 提供面向企业的 API 监控解决方案，该解决方案与 REST 和 SOAP API 协议接口。监控由分析和可自定义的停机时间警报提供支持，并为企业提供数据以满足服务级别协议 (SLA) 和客户期望。

APImetrics 的机器学习和标准主管 Paul Cray 博士表示：“过去十年，经济正日益成为数字经济，而数字经济也日益成为 API 经济。新冠肺炎疫情的爆发加速了这一趋势。有意义、可量化、可衡量的全球质量标准对于最大限度地发挥 API 创建者和用户在众多行业提供的价值至关重要。这就是 OpenAPI Initiative 和 APImetrics 如此完美契合的原因，我期待与 OAI 合作制定这些标准。”

APImetrics 对与 OAI 合作制定标准特别感兴趣，这些标准可以帮助定义和衡量服务级别目标，以及围绕 API 的认证、合规性、一致性和持续测试和监控等问题。

OpenAPI Initiative 技术指导委员会成员、Google Cloud 产品经理 Marsh Gardiner 表示：“APImetrics 是 OpenAPI Initiative 的一个受欢迎的补充。当行业携手解决常见的 API 描述难题时，例如 描述 SLO 和 SLA，每个人都将获益。”

OpenAPI 资源

要详细了解如何参与 OpenAPI 规范的演变，请访问：https://www.openapis.org.cn/participate/how-to-contribute

加入我们参加 ASC 2020

立即注册参加 2020 年 API 规范大会，9 月 9 日至 10 日

关于 OpenAPI Initiative

OpenAPI Initiative (OAI) 由一群具有前瞻性的行业专家创建，他们认识到标准化 API 描述方式的巨大价值。作为 Linux 基金会下属的一个开放治理结构，OAI 专注于创建、发展和推广供应商中立的描述格式。OpenAPI 规范最初基于 Swagger 规范，由 SmartBear 软件捐赠。如需参与 OpenAPI Initiative，请访问 https://www.openapis.org.cn

关于 Linux 基金会

Linux 基金会成立于 2000 年，拥有 1,000 多个成员的支持，是全球领先的开源软件、开放标准、开放数据和开放硬件协作平台。Linux、Kubernetes、Node.js 等 Linux 基金会项目被认为是全球最重要的基础设施发展不可或缺的一部分。其开发方法利用了已建立的最佳实践，并满足了贡献者、用户和解决方案提供商的需求，为开放协作创建了可持续的模式。有关更多信息，请访问 linuxfoundation.org。

8 月 13 日
喜欢0

ASC 演讲嘉宾公布！

作者 博客

2020 年的演讲嘉宾已公布，他们的演讲涵盖了专家技术人员、商业专业人士、开源贡献者等多个领域！从 GitHub、Google、Microsoft、MuleSoft、OpenTravel Alliance、Postman、SmartBear、TravelPort、Vonage 等公司和组织那里学习。一些亮点包括

处理遗留系统？请阅读 Marc-André Giroux 和 Andrew Hoglund 在 GitHub 上撰写的“从 0 到 OpenAPI：使用 OpenAPI 在 GitHub 上描述 10 年前的 API”。

想要了解应对大流行的技巧？请观看 Jeff ErnstFriedman 在 OpenTravel Alliance 上撰写的“所有互操作性，但没有接触”。

暗中对 Postman 如何测试其自身技术感兴趣？请参加 Joyce Lin 在 Postman 上撰写的“Postman 如何使用 Postman 构建 API”。

好奇如何实施统一的 API 设计流程，该流程超越了采用单一 API 风格或规范？您一定想查看 Mike Amundsen 在 amundsen.com Inc. 上撰写的“GraphQL、gRPC 和 REST，哦，我的天哪！一种统一 API 设计方法”。

渴望为开发人员体验注入乐趣？也许 Lorna Mitchell 在 Vonage 上撰写的“从 OpenAPI 创建令人愉快的 SDK”正是您的杯中茶。

提升您的技能，结识同行，了解最新的研究和最新的真实案例研究。ASC 2020 是今年的虚拟会议，于 9 月 9 日至 10 日举行。

立即查看完整日程安排！https://asc2020.sched.com/

立即注册！https://events.linuxfoundation.org/openapi-asc/register/

ASC 2020 - API Specifications Conference - Virtual Experience, September 9 - 10. Hosted by the OpenAPI Initiative
7 月 23 日
喜欢0

Postman 加入 OAI 以支持 OpenAPI 规范

作者 公告，博客

这篇博文由 Postman 首席布道师 Kin Lane 撰写。

当 Postman 去年推出其 API 构建器时，我们惊讶地发现 OpenAPI 在用户设计和开发 API 方面如此受欢迎。我们的使用数据帮助我们意识到 OpenAPI 规范对客户设计和构建 API 的方式有多重要。今天，Postman 加入 OpenAPI Initiative，以便与其他 35 个 OAI 成员一起推动规范的向前发展。我们希望共同继续支持基于规范构建的开源工具，并发展一个更强大的 OpenAPI 社区，以确保这一重要行业标准的未来。

从历史上看，Postman 集合是 API 提供者在平台上定义 API 的方式。随着 API 构建器的推出，越来越多的 API 提供者开始使用 OpenAPI 作为开发的每个 API 的核心定义。多年来，Postman 集合已经发展到允许开发人员测试、模拟、记录和自动化 API 生命周期的一部分。随着这种演变，每个集合都可以从 OpenAPI 生成，推动我们提供越来越多的特定功能，帮助客户利用 OpenAPI 作为 API 合同，在整个 API 操作中使用。

  • 导入 – 您可以将 OpenAPI 文档导入 Postman 并将其作为每个单独 API 的核心合同维护，用于在文档、集合或测试与 OpenAPI 合同不同步时进行验证和通知开发人员。
  • 生成 – 您可以从 OpenAPI 定义生成 Postman 集合，建立 API 合同的派生产品，以便在跨区域的持续操作中用于记录、模拟和测试 API。
  • 验证 – 从 OpenAPI 规范生成的每个集合都可以根据 OpenAPI 合同进行验证，有助于保持文档、模拟服务器和测试基础设施在整个操作中的对齐。
  • GitHub 同步 – 当您使用 API 构建器在 Postman 中管理 OpenAPI 文档时，您可以将其同步到 GitHub，使其可在其他系统中使用，允许在 Postman 或通过其他工具进行更改。

OpenAPI 已成为 Postman 客户的 API 工厂车间的一部分。除了规范描述的内容外，Postman 使得 API 的使用变得更加容易，因为它允许您为多个配置文件或生命周期阶段存储令牌或密钥，并为运行测试或监控添加特定值。OpenAPI 规范提供了一种定义 HTTP API 的可能性的方法，而 Postman 集合则作为一种定义、执行和自动化 API 生命周期中每个步骤的方法出现。OpenAPI 和 Postman 之间更牢固的关系帮助了我们的客户，我们很高兴能够加入关于 OpenAPI 路线图可能是什么的讨论，并帮助实现跨 API 生命周期使用 OpenAPI 的全部好处。

7 月 20 日
喜欢0

宣布新的 OpenAPI Initiative 旅游特别兴趣小组

作者 公告，博客

加入 OpenTravel 和 OpenAPI Initiative 旅游工作组，于 2020 年 7 月 22 日将重点放在欧洲旅行者身上。点击 这里 获取 Zoom 邀请。如需获取所有最新的更新和公告，请点击 这里 并注册定期更新！

旅游业依赖于 API。在旅游、观光和酒店等不同行业之间建立业务联系，并代表需要有效沟通和传递电子信息的众多公司，包括航空公司、租车公司、酒店、旅行社、旅行社、科技公司等等。

考虑到这一点，OpenAPI Initiative 正在创建一个旅游特别兴趣小组 (SIG)，以支持 API 的采用，并促进整个旅游行业的数字化转型。

OpenAPI TravelSIG 的使命是“通过推广 OpenAPI Initiative，促进整个旅游垂直领域 API 采用、开发和开发人员的增长”。它将根据需要开会，讨论旅游领域的常见挑战和解决方案，并提供一个统一的声音，与 OAI 的技术指导委员会进行协调，并根据 TSC、TOB 或 BGB 的请求，以临时形式进行组建。

Travel SIG 将指定一个联络人，以便根据需要与 OpenAPI 内的理事会和其他机构进行沟通。

OAI 的任何成员都可以参与 Travel SIG。非成员的参与（我们喜欢说“即将成为成员！”）将根据具体情况允许，以提供相关的主题专业知识，并帮助作为拓展机会，为 OpenAPI Initiative 带来新的成员和采用者。

请加入 Travel SIG！点击 这里 获取 2020 年 7 月 22 日下一次会议的 Zoom 邀请，并 这里 注册定期更新！

7 月 17 日
喜欢0

ASC 2020 – 主题演讲嘉宾

作者 博客

我们很高兴地宣布两名 ASC 2020 主题演讲嘉宾将于 9 月 9 日至 10 日在您的沙发上虚拟举行。

Keynote Speaker, Lorna Mitchell. Developer Advocate and API Enthusiast, Vonage

Lorna Mitchell 是一位多面手软件开发人员和开发人员关系专业人士，她将加入我们，分享她丰富的智慧。Lorna 丰富的 API 经验以及幽默地提醒我们截止日期让我们忘记的最佳实践的能力，保证了这次会议将是值得花时间参加的。

Keynote speaker, Mark Nottingham. Senior Principal Engineer, Fastly.

马克·诺丁汉 这个名字对于许多需要阅读 IETF 规范来解决 API 问题的人来说并不陌生。无论您需要格式化错误负载、解析 URI 模板，还是讨论知名 URL 的相对优点，马克都是一个丰富的合理意见宝库，这些意见都来自于多年的经验。

加入我们 https://apispecs.io，您的 API 会感谢您。

6 月 23 日
喜欢0

OpenAPI 欢迎 OpenTravel Alliance 加入新成员

作者 公告，博客


OpenAPI 欢迎 OpenTravel Alliance 成为其最新成员！

OpenTravel 是一个非营利性行业协会，致力于开发数据消息结构，以促进旅游业各个方面的沟通。它是旅游行业唯一的开源互操作性数据标准。使用 OpenTravel 消息，旅行者可以在完全无接触的环境中搜索、预订、支付和办理入住/退房手续。

“我们看到 OpenTravel Alliance 的使命与 OpenAPI Initiative 的使命之间有着坚实的战略一致性，”OpenTravel Alliance 执行董事杰夫·恩斯特弗里德曼说。“我们共享一个在 API 经济中推广开放标准的目标，而 OAI 是生成 API 市场的所有方面的中心。我们期待将旅游行业的意见带到 2020 年 API 规范大会，该大会将于 9 月 9 日至 10 日举行。”

目前有数万个 OpenTravel 消息结构正在使用。开源标准涵盖航空、铁路、游轮、高尔夫、旅游套餐、地面交通、酒店和汽车租赁。该组织最初使用 XML 消息系统，但此后已将 OpenTravel 消息提供给 JSON、WSDL 和 OpenAPI 规范。

为了帮助旅游业适应 COVID-19，OpenTravel 推出了新的 COVID 协议消息系统。在即将发布的版本中，OpenTravel 消息将包含使旅游公司能够利用积压的需求并增加收入的功能。

“我们的技术允许供应商之间实现互操作性，这将增加收入机会并降低技术成本，”恩斯特弗里德曼说。“OpenTravel 消息的互操作性组件将允许无缝的旅行者体验，这将减少物理接触点并加快旅行者在整个旅程中的移动。”

“OpenTravel Alliance 是 OpenAPI Initiative 的一个令人兴奋的补充，”Google Cloud 产品经理兼 OpenAPI Initiative 技术指导委员会成员马什·加德纳说。“标准化 API 的描述方式以简化开发对许多不同的行业来说都是有意义的，而旅游业尤其可以从中受益。”

OpenAPI 资源

要详细了解如何参与 OpenAPI 规范的演变，请访问：https://www.openapis.org.cn/participate/how-to-contribute

关于 OpenAPI Initiative

OpenAPI Initiative (OAI) 由一群具有前瞻性的行业专家创建，他们认识到标准化 API 描述方式的巨大价值。作为 Linux 基金会下属的一个开放治理结构，OAI 专注于创建、发展和推广供应商中立的描述格式。OpenAPI 规范最初基于 Swagger 规范，由 SmartBear 软件捐赠。如需参与 OpenAPI Initiative，请访问 https://www.openapis.org.cn

关于 Linux 基金会

Linux 基金会成立于 2000 年，拥有 1,000 多个成员的支持，是全球领先的开源软件、开放标准、开放数据和开放硬件协作平台。Linux、Kubernetes、Node.js 等 Linux 基金会项目被认为是全球最重要的基础设施发展不可或缺的一部分。其开发方法利用了已建立的最佳实践，并满足了贡献者、用户和解决方案提供商的需求，为开放协作创建了可持续的模式。有关更多信息，请访问 linuxfoundation.org。

6 月 18 日
喜欢0

OpenAPI 3.1.0 RC0 发布了！

作者 博客

时间过得真快！我们发布 OpenAPI 3.0.0 已经快三年了。在这段时间里，我们进行了一些补丁版本发布，这些版本大多是微小的澄清和更正。然而，今天不同了。

今天，我们宣布 OpenAPI 3.1.0 的第一个候选发布版。

闪亮的东西

此新版本中的三个重大更改包括

  • 一个新的顶级元素，用于描述在带外注册和管理的 Webhook。非常感谢 Lorna Mitchell 推动这项工作，使用我们全新的 提案流程 并经常提醒我们专注于发布。
  • 支持使用标准 SPDX 标识符标识 API 许可证。
  • PathItems 对象现在是可选的，以便更轻松地创建可重用的组件库。可重用的 PathItems 可以描述在 components 对象中。还支持描述使用客户端证书保护的 API。

完美契合

虽然这些增强功能（以及我们在 发行说明 中描述的许多其他功能）解决了 OpenAPI 开发者社区中一些最需要的功能，但它们的光芒都被我们在 OpenAPI 3.1.0 中做出的最重大改进所掩盖。此版本的 OpenAPI 规范现在支持与最新版 JSON Schema 的 100% 兼容。 这是 OpenAPI 开发者社区和 JSON Schema 社区成员之间的一项重大努力。特别感谢 Henry Andrews、Phil Sturgeon 和 Ben Hutton 为他们提供的辛勤工作、支持和耐心的解释。

微小的变化带来重大差异

对于 OpenAPI 描述的常规用户来说，3.1.0 Schema 对象中的差异可能不会立即显现出来。事实上，v3.0.x 描述将非常乐意通过 v3.1.0 验证。可以增量地采用新功能。最新版 JSON Schema 支持许多新功能，但我们将把这些细节留到以后的博文中进行介绍。

当微小的变化是重大的

在 OpenAPI v3 规范中，我们采用 语义版本控制 来传达更改的重要性。语义版本控制是一种流行的方法，它最初是为管理软件包而创建的。次要版本更新表示更改是向后兼容的，而主要更新则不是。谈论规范时，向后兼容的更改意味着什么并不明显。在 v3.0.3 中，我们 引入了语言 试图准确地说明向后兼容的更改意味着什么。我们天真地认为这会有所帮助。

在讨论与 JSON Schema 对齐的最终细节时，我们发现与 readOnly 和 writeOnly 属性存在特别棘手的問題，这些属性在 JSON Schema 中定义，但在 OpenAPI 中描述为具有略微不同的行为。为了实现我们与 JSON Schema 完全对齐的目标，我们不得不放弃 OpenAPI 的行为。从技术上讲，此更改可能会“破坏”那里的一些工具。我们还没有找到它（我们还在寻找）。语义版本控制会坚持将此更改表示为 4.0.0。但是，此规范更新并非如此重大的更新，而是有一些小的破坏性更改。

OpenAPI 规范 4.0.0 的发布会带来一系列期望。主要版本升级通常也会面临采用阻力。此 OpenAPI 更新不是主要更新——它有一些很好的改进，并且我们现在与 JSON Schema 处于更好的轨道上，但是强迫它成为主要版本会导致期望不符。

这种难题导致 技术指导委员会 对这个问题进行投票，因为我们无法首次达成共识。正如您可能猜到的，最终决定是放弃语义版本控制的要求。虽然对这是否正确尚存争议，但这为我们在将来提供了空间，以便更好地使用主要和次要版本号，更准确地传达版本更改对大多数用户的意义。

瞧！

因此，OpenAPI 3.1.0 RC0 已准备好进行最终审查，这是您在它毕业之前发表评论的邀请。在我们解决任何最后的收尾问题之后，我们将宣布 3.1.0 完成并发布！

关闭菜单