跳到主要内容
搜索
类别

博客

六月 07
喜欢0

RepreZen 加入 Open API Initiative，宣布早期 OAS 3.0 工具支持

作者 博客

OpenAPI 规范 (OAS) 版本 2.0，以前称为 Swagger 规范，是当前行业标准，用于 API 描述，得到了数千个开源项目和所有主要 API 技术供应商的支持。而 OAS 版本 3.0，计划于 2017 年 7 月发布，是对规范的首次重大更新。

OpenAPI 3.0 可以更精确详细地描述更广泛的现代 REST API。它提供了改进的组件重用、更灵活的消息模式和新的 API 功能，如超链接和回调。

RepreZen 很高兴宣布，在我们的商业和开源软件中，对 OpenAPI 3.0 提供了实验性编辑支持，将这些新功能直接带到了开发人员的桌面。我们的第一个实现基于当前的 草案规范，并使用 Gnostic JSON Schema for OpenAPI，由 Google 的 Tim Burks 贡献。

RepreZen 加入 Open API Initiative

我们还很自豪地宣布，RepreZen 现在是 Open API Initiative 的成员，我们将继续作为技术开发社区的一部分，参与 OpenAPI 规范。

与 OpenAPI 社区合作对我们来说是一次令人欣慰的体验，因为我们从 SmartBear、Google、Microsoft 等公司获得了丰富的知识和思想领导力。他们信守承诺，保持着该小组的开放性和供应商中立性。凭借 Swagger，他们继承了丰富的实践知识，这些知识在 GitHub（和其他地方）的讨论线程中得到了阐述，并提炼成了 OpenAPI 规范 本身。

对于 RepreZen 团队来说，这为我们几年前就开始的参与以及我们对 OAS 作为行业标准 API 描述语言的支持盖上了官方印章。

对于我们的客户来说，加入 OAI 是我们对将 OAS 作为 RepreZen 产品和开源技术的中心的承诺，我们将继续创新和构建解决方案，让 OpenAPI 为您服务。

关于 OpenAPI 的想法，过去和未来

伟大的软件是关于在中间相遇的。

如果您像我一样是一个有想法的人，您会从抽象的角度来看待它，描述问题和解决方案的本质，最大限度地洞察问题和解决方案，并尽可能减少实现细节。您会寻找最高级别、最具表现力的方式来以机器可读的形式表示它，然后向下钻取到实现细节，但只钻取到您需要的程度。

如果您是一个实用主义者，您会从基础开始，从机制开始，并重构您的方式来获得更优雅的解决方案。  但只有在优雅不再为自身买单时才会停止。然后你就会停下来，把粗糙的边缘留到将来再处理，然后继续前进。

但是无论您从哪个角度来看，这都是一个不断协调的过程。软件的演进意味着概念框架和代码的并行演进；并且不断地、巧妙地将它们编织在一起。您自上而下和自下而上地工作，并在中间相遇。

OpenAPI 规范是恰到好处的抽象可以做到的一个很好的例子。它提供了一个表达能力的提升，允许开发人员考虑资源、操作和数据模型——熟悉的概念，在协议、控制器和类的顶篷之上以舒适的高度滑翔。  而且您不必以高级语义、深奥的概念或宗教教条来重新思考您的 API。

借助丰富的商业和开源工具生态系统，开发人员可以选择自下而上工作，使用代码优先注释，或者自上而下工作，使用 API 描述语言。无论您从哪里开始，我们都可以通过 OpenAPI 规范在中间相遇。

让我们谈谈 API！

想参与进来吗？我们敞开大门，我们喜欢倾听用户的意见。

  • 联系我们，让我们知道您对 OpenAPI、RepreZen API Studio 和 KaiZen Editor 的看法。
  • 发布问题 在 GitHub 上发布 KaiZen OpenAPI Editor 的问题，或访问我们的 支持和社区网站 了解 RepreZen API Studio
  • 如果您想为 KaiZen Editor、KaiZen Parser 或我们的其他 开源项目 贡献改进，请发送电子邮件至 [email protected]。  我们欢迎认真的代码贡献。

RepreZen API Studio：OpenAPI 开发的完整 IDE 

RepreZen API Studio 是我们面向 API 优先设计、文档和开发的旗舰平台。

要开始使用，只需 注册免费试用，下载并安装。  查看我们的支持网站上的 常见问题解答文章 以开始使用。

KaiZen OpenAPI Editor：现已在 Eclipse Marketplace 上架

KaiZen OpenAPI Editor 是 RepreZen 的开源、基于 Eclipse 的编辑器，用于行业标准的 OpenAPI 规范语言。这是 RepreZen API Studio 使用的相同功能齐全的编辑器，以前称为 SwagEdit。  KaiZen OpenAPI Editor 是我们用于 OpenAPI 2.0 和 3.0 的核心编辑组件。

您可以通过从 Eclipse Marketplace 安装到 Eclipse 桌面 IDE（Mars.2 版本或更高版本）来试用它。安装完成后，请参阅 入门指南 以快速概览。   

Ted Epstein
RepreZen 首席执行官
RepreZen 首席执行官 Ted Epstein 十多年来一直在帮助组织简化、统一和协调其系统接口。Ted 领导 RAPID-ML 架构，RAPID-ML 是第一个将协作数据建模功能引入 REST API 设计的 IDL。Ted 是 API-Craft NYC Meetup 的联合组织者，并在 QCon、EclipseCon、API-Craft 和 Data Modeling Zone 等会议上发表过演讲。
五月 25
喜欢0

Open API Initiative 向您发送“留个日期”卡片

作者 博客

我们即将发布 OpenAPI 规范 v3.0.0 最终版。如果您一直在等待开始试用 OpenAPI 规范 (OAS) v3.0.0（前身为 Swagger），那么现在是开始原型设计或编码的时候了。**请在您的日历上标记从 6 月 19 日（星期一）到 6 月 30 日（星期五）的为期两周的最后评论期**，并关注 7 月份的最终发布。

3 月 1 日，Open API Initiative (OAI) 宣布 发布首个 OpenAPI 规范 v3.0.0 实现者草案。此版本被标记为 3.0.0-rc0，我们还在 4 月底发布了后续版本，标记为 3.0.0-rc1。

在 5 月 19 日（星期五）的会议上，技术开发社区 (TDC) 同意将发布目标设定为以下时间线

  • 从 5 月 22 日到 6 月 16 日的 4 周：解决剩余的拉取请求
  • 从 6 月 19 日到 6 月 30 日的 2 周：评论期
  • 从 7 月 3 日到 7 月 14 日的 2 周：解决剩余的评论和问题
  • 从 7 月 17 日到 7 月 21 日的 1 周：TENTATIVE 发布窗口

如果您没有收到关于 OpenAPI 规范存储库中每次更改的移动设备推送通知，以下是一些有用的链接

如上所述，**如果您还没有这样做，现在是审查最新 OpenAPI 规范 v3.0.0 的好时机**，考虑您的系统和工具如何利用 新功能，并在 v3.0.0 最终版发布之前考虑是否有任何地方可以改进。

最后，如果您正在编写任何使用 3.0 草案规范的工具，请通过完成此 非常简短的调查 告知我们，因为只有通过针对草案规范实现代码，我们才能对它的准备情况充满信心！

Tony Tam
SmartBear 软件 Swagger 产品副总裁
Jeremy Whitlock
谷歌软件工程师
Ron Ratovsky
SmartBear 软件 Swagger 开发者布道师
Darrel Miller
微软软件开发人员
Marsh Gardiner
谷歌产品经理
Jason Harmon
Typeform 的 API 负责人
May 02
喜欢0

竞争对手加入 OAI 引领 API 环境的融合

作者 博客
随着 Mulesoft（RAML 的创始公司）最近加入 Open API Initiative，以及 Apiary（API Blueprint 的创始公司）和 SmartBear（Swagger 的管理者）也成为 Open API Initiative 的成员，Restlet 的 Jerome Louvel 抓住了这个机会，回顾了 OAI 和 API 规范的历史。

与其让这三者之间直接竞争下去，希望其中一个能够获胜并取代另外两个，不如找到一条更好的路径。我与这个故事的主要参与者关系密切，并构建了像 Restlet Studio 这样的工具，它支持 OAS 和 RAML，同时倾听用户的意见，我意识到，理想情况是让 Apiary 和 MuleSoft 加入 Open API Initiative，并逐步推动这三种规范的融合，而不是合并。在 API 测试方面，也存在类似的标准化需求，但除了 HAR（HTTP 档案）格式外，只有专有格式可用，例如 Postman Collections 或 JMeter Scripts。

阅读 Restlet 博客 上的完整文章。

 

 

注意：Restlet 是 OAI 的创始成员，最近加入了 RAML 工作组。

 

Jerome Louvel
Restlet 的首席技术官兼产品副总裁
Jerome Louvel 是 Restlet 的创始人、首席技术官兼产品副总裁，也是 REST API 专家。Jerome 是 Open API Initiative 业务管理委员会成员
Apr 13
喜欢0

Open API Initiative 和 Linux 基金会将联合举办 APIStrat 17

作者 博客

Open API Initiative 与红帽的 3scale 和 API Evangelist 欣然宣布，APIStrat 已成为 Linux 基金会活动。

API 策略与实践大会将于 10 月 31 日至 11 月 2 日在俄勒冈州波特兰举行。将由 Linux 基金会活动和 Open API Initiative (OAI) 联合举办。

在过去的七年里，APIStrat 由 3scale 组织，3scale 于 2016 年 6 月被红帽收购，他们已将该活动捐赠给 Linux 基金会。该会议的第八届将汇集各种与会者，从对 API 感兴趣的人到开发人员和 IT 团队、业务用户和高管，讨论 API 领域的机会和挑战。

“我们很高兴看到 APIStrat 转移到 Linux 基金会和 Open API Initiative 的管理之下。自成立以来，该大会一直致力于提供一个供应商中立、高质量的空间来讨论最新的 API 主题，我相信新的组织团队将出色地管理它。与 Open API Initiative 一样，我们也致力于为 API 定义采用一种标准的通用格式，并将该活动视为一个很好的契合点。”红帽 API 基础设施高级总监兼负责人 Steven Willmott 说。

“经过七届活动，我很高兴看到 APIStrat 作为会议日益成熟，并成为 Open API Initiative (OAI) 的一部分。该活动长期以来一直是围绕 Open API（又名 Swagger）进行讨论的论坛，因此 Linux 基金会是举办该会议的最佳选择。”APIStrat 联合创始人兼 API Evangelist Kin Lane 说。

Linux 基金会在全球举办 100 多场活动，汇集全球领先的技术专家，共同合作和创新。

Mar 01
喜欢0

Open API Initiative 宣布发布 OpenAPI Spec v3 实现者草案

作者 博客

大约一个月前，我们承诺推出 OpenAPI Specification (OAS) 的第一个实现者草案，现在它已经发布了！按照我们的官方版本控制方案，这个版本被称为 3.0.0-rc0。这是朝着发布规范的最终版本迈出的重要一步。

在最终版本发布之前，规范的进一步开发将在 OpenAPI.next 分支 中进行。3.0.0-rc0 版本已 标记 作为固定的参考。

自我们 上次博客文章 以来，我们已经解决了规范中剩余的结构性更改，并澄清了一些问题和疑虑，并改进了文档。自那以后，一些值得注意的更改包括：

  • 最终确定对 URL 模板的支持。
  • 重新设计对“multipart/*”和“x-www-form-urlencoded”的支持，更改了文件上传的处理方式，并删除了“file”类型和“formData”参数类型。
  • 请求体现在正式 不支持 HTTP 动词，因为其行为未定义。
  • 澄清了如何处理作为值的相对 URL。
  • 回调的表达式语言已重新设计。
  • 示例文档已澄清。
  • Schema 对象已更新，以支持“nullable”用于空传输值，并且还添加了 writeOnly 属性。
  • 对 JSON Schema 的支持已更新至 version draft-wright-json-schema-00（也称为 Draft 05）。已澄清 OAS 实现和 JSON Schema 之间的差异。
  • Header 对象已更新，以遵循与 Parameter 对象类似的标准。因此，Items 对象已被删除。

目前，规范已“功能完整”，这意味着我们不会积极讨论添加对现有问题的支持。在接下来的几周内，我们将关闭已处理的问题或将它们标记为未来版本。

下一步是什么？

实现者草案标志着规范第三代的转折点。正如我们在 2.0 版本中所观察到的那样，没有工具，规范就毫无意义；没有规范，工具就毫无意义。这个草案意味着所有重大更改都已完成，并且鼓励工具作者基于此构建，因为从现在开始，只会进行少量更改。与 2.0 版本一样，这是一个早日行动、提升项目知名度的绝佳机会。这也是参与 OpenAPI 社区、帮助推动规范发布的有意义的方式。

这意味着球在你手中。以下是你如何提供帮助：

  • 编写自己的工具，添加对规范的支持——毕竟它只是一个实现者草案。这是我们唯一了解这些更改是否有效、发布的内容是否可行以及能否完全实现的方式。正在开发此类工具？请在 OpenAPI Specification Repository 中提交问题告知我们！
  • 查找规范中的技术问题：规范各部分之间的矛盾、毫无意义的功能、我们未曾考虑的用例。确保跟踪主题的线程和 PR，以查看当前实现是否存在现有理由。
  • 查找规范中的内容问题：缺少句号、错别字、错误的示例、措辞不当等等。

对贡献最大的个人，Open API Initiative 会给予感谢。

与之前一样，我们可能会要求对特定问题进行贡献或反馈——这些问题将被标记为“需要帮助”。密切关注这些问题，不要害怕加入讨论。

感谢所有为这一重大进步做出贡献的人，并期待 OpenAPI Specification 版本 3.0.0 的最终发布。

技术开发者社区

Tony Tam
SmartBear 软件 Swagger 产品副总裁
Jeremy Whitlock
谷歌软件工程师
Ron Ratovsky
SmartBear 软件 Swagger 开发者布道师
Darrel Miller
微软软件开发人员
Marsh Gardiner
谷歌产品经理
Jason Harmon
Typeform 的 API 负责人
Jan 24
喜欢0

新年新规范

作者 博客

这是一段激动人心的旅程，我们很高兴地宣布 OpenAPI Specification 版本 3.0 即将发布！

Image from the most recent Meeting of the Open API Initiative Technical Developer Community Meeting

来自最近一次 Open API Initiative 技术开发者社区会议的图片

在过去的一年里，技术开发者社区 (TDC) 筛选了数百个问题和数千条评论——所有这些都旨在整合社区成员的需求，并改进 2.0 规范以满足他们的需求。我们倾听、辩论、达成一致、并发表不同意见，始终保持规范的简洁和实用性，同时又强大有力。下一个重要的里程碑将是第一个实现者草案，它将于**2017 年 2 月 28 日**发布。

变化

在过去的几个月里，我们通过一系列博客文章、演讲以及规范本身的变更，发布了关于规范即将变更的消息。以下是一些值得注意的变更的简要回顾。

  • 重新排列了规范的结构，以方便和扩展重用。
  • 扩展了 JSON Schema 支持，包括 `oneOf`、`anyOf` 和 `not` 支持。
  • 更改了参数的结构，允许在其中使用 schema。
  • 添加了对 Cookie 参数的支持，并消除了 dataForm 参数。
  • 将 Body 参数提取到它们自己的实体。
  • 添加了对内容类型协商的支持。
  • 引入了一种新格式，允许在响应和未来的请求之间进行静态链接。
  • 简化和增强了 API 的安全定义。
  • 添加了回调机制来描述 WebHooks。

为了帮助工具开发人员，我们还承诺对规范进行语义版本控制。这意味着对规范的任何更改都将触发版本更新，从而更易于管理和控制。

实现者草案

经过这么多对规范的投入，是时候让开发人员开始在实际场景中证明它的用处了。因此，这份实现者草案是迈向最终版本的重要一步。随着更广泛的受众提供反馈，并解决任何由此产生的问题，它将使我们最终发布。今天，我们呼吁您开始使用该规范，并帮助我们确保它以最高质量实现其目标。

下一步

这也意味着规范的主要更改不应该再被引入。这并不意味着规范已经完全准备好了，但我们已经开始专注于清理文档，以帮助使新的规范更易于使用。

因此，在接下来的几周内，TDC 将集中精力关闭已解决的票据，并为将来的版本标记票据。我们还将验证规范是否包含所有必要的信息，包括适时的澄清和示例。

作为社区成员（是的，您！），请查找任何标记为“需要帮助”的票据，这表示需要帮助来解决未解决的问题。与往常一样，请随时提交额外的票据和 PR，无论发布状态如何。

关闭菜单