GlueCon 2014 会议总结：Swagger 2.0 工作组及未来展望

在2014年科罗拉多州举行的GlueCon会议上，Swagger的创始人兼Reverb CEO Tony Tam发表了题为《Swagger APIs for humans (and robots)》的演讲，宣布了Swagger 2.0工作组的成立，并展示了一个早期版本的在线代码编辑器，该编辑器能够动态地将YAML转换为Swagger UI。

Swagger 2.0 工作组宣布

Tony Tam正在组建一个供应商中立的工作组，目标是今年夏天发布Swagger 2.0版本。新版本将包括对YAML语法的开箱即用支持、涵盖SLA的额外元数据、供应商扩展等。一个新网站已经上线，供感兴趣的各方加入。

Swagger 2.0规范很可能与之前的版本不兼容，但将提供迁移路径，并升级整个工具链。此外，正式的JSON Schema将减少之前版本中遇到的兼容性问题。Reverb已经开始与Jackson的创建者Tatu Saloranta合作，Jackson是一个流行的Java JSON库。

另一个目标是提供独立的Java和Scala工具链，以更好地与每种编程语言集成，所有这些都基于Mustache代码模板。该工具链还将优化以减少内存和CPU资源的使用。Tony还希望“使编写和部署基于Swagger的Web API尽可能容易，使用如APISpark、AWS、Heroku等云平台。”

官方成员之间的协作将在Google Group和GitHub仓库中进行，个人成员也可以提交pull请求。已经加入Reverb和创始成员Apigee的公司包括3Scale、SmartBear和Restlet。

Tony还在演讲中推出了一个在线Swagger编辑器预览版，允许开发者用YAML编写Swagger定义（基于Swagger 1.2规范），并查看动态更新的Swagger UI。该组件基于AngularJS和Ace代码编辑器开发，由API管理公司Apigee贡献给Swagger项目。该编辑器还能够在线生成服务器骨架和客户端SDK。

Swagger项目的现状

2014年3月，Swagger 1.2规范发布，Tony声称Swagger拥有最大和最活跃的社区，外部贡献现在超过了Reverb的贡献。Tony指出，“Swagger用于进行‘非Hello World’的部署，估计有10,000个生产部署和大约500,000次下载，仅2014年。”

Tony认为，Swagger正在尝试解决与RAML、WADL或API Blueprint相同的问题，但采用了不同的方法。他认为“技术格式不如底层元模型重要。Swagger JSON可以自动转换为YAML，反之亦然。”然而，他认为API Blueprint使用的“wiki/markdown格式”对人类友好，但对机器处理更困难，我们需要支持这两种类型的用户。

在GlueCon 2014的“API策略与实践”闪电演讲中，Tony解释说，API开发者之间的采用将产生真正的差异，并设定事实上的标准。API Blueprint的创建者兼Apiary CEO Jakub Nesetril在随后的研讨会中承认，Swagger在采用方面具有优势。最近的InfoQ调查也将Swagger列为最受欢迎的解决方案。

Tony强调，Swagger是“唯一在所有方面都是开源的解决方案（Apache 2.0许可证），包括规范和所有工具，并且真正是供应商中立的。Swagger试图在设备、应用程序和服务之间实现连接，而不是通过服务控制整个堆栈。”

客户端SDK是必要的恶

在GlueCon早些时候，RunScope CEO John Sheehan强调了客户端SDK的常见问题：1. SDK版本没有与API版本同步演进。2. 异构SDK依赖于相同依赖项的不同版本，如JSON或HTTP库。3. 为主要的编程语言构建SDK很难，即使对于较大的公司也是如此。

Tony间接回应说，“客户端SDK确实很难维护，你需要语言专家来编写客户端SDK模板，否则它确实无法工作，你不能要求用户编写客户端SDK。”然而，他认为它们仍然是必要的，并举例说“AWS在抽象其Web API的复杂性方面做得很好（他们隐藏了它），但这对于较小的公司来说不起作用/无法扩展。”他还提到Reverb的iPhone应用程序（也在Gluecon上推出）使用自动生成的Objective-C客户端SDK，并说“手动构建它将花费数周到数月的时间，并减慢API服务器的整个迭代过程。”

超越SOAP和HTTP/1.1

Tony进一步认为，“构建块是服务，软件是聚合器，Swagger正在帮助实现这一愿景。”他还认为，“SOAP从未流行起来，因为许多流行语言如Ruby和Python被排除在外。”此外，他认为“供应商污染可能会破坏API规范的采用，引用CORBA作为一个由于供应商特定功能而失败的例子，这些功能破坏了精神。”

相反，他指出Swagger是“框架、语言和部署无关的。”他还认为，“从长远来看，HTTP将被其他协议取代，但无论你使用什么，你仍然需要描述服务。”他将HTTP/1.1描述为“太冗长，开销太大，当你有一个全双工、二进制连接可用时，你可能永远不会通过HTTP使用你的数据库。”

他提到了现有的基于WebSocket的Swagger实现或二进制协议如Avro、Thrift或ProtoBuf的存在。看看即将到来的基于Google SPDY实验的HTTP/2.0协议，包括二进制序列化和全双工模式，是否会对性能敏感的Web API更有效，这将很有趣。

无论如何，Swagger 2.0旨在提供一个稳定的API描述语言，即使底层协议在演进，它也能同样良好地工作，在某种程度上是Web API的更好的SOAP。你认为Swagger项目能够实现这些新想法吗？此外，你认为竞争的Web API语言会如何反应？

免责声明：本文作者在Restlet工作，Restlet是一个支持多种Web API语言的Web API平台提供商，包括Swagger。