根据Greg Brail的说法，习惯于Web和移动世界的开发者越来越多地转向API，把它当作连接客户端与服务器的有效手段。随着这些开发者遭遇像企业之间业务对业务连接这类的应用对应用问题，他们的第一反应往往是，“这里为什么我们不能用一个API就行了呢？”

在本次的SearchSOA采访中， Brail回答了这个用API还是中间件的问题，并对比了基于API的集成与SOA级企业服务总线（ESB）方案。他还就变更管理、XML与JSON数据格式以及超媒体的使用等API问题提供了建议。

作为O’Reilly出版的《API：策略指南》一书的联合作者，Brail拥有很长一段中间件开发史。他为花旗银行开发了中间件库，是交易的的首席架构师兼BEA WebLogic JMS技术领导。在API及中间件后端即服务提供商Apigee，他是所有产品的架构领导。

API什么时候该替代集成中间件？为什么？

Greg Brail：正如API对于最苛刻的移动应用够快，对于重要的面向消费者用例足够安全那样，它们也没理由不能成为集成任务的默认选择。如果API可以用来替代的话，几乎没有什么理由采用更传统的应用对应用协议或者集成技术。

我认为，例外要比大家认为的要少要远。一个好的例子是像发生频率很高的金融交易，其吞吐量以及延时都非常极端，以至于哪怕是TCP（且不说HTTP）都太慢了。

哪怕是像消息队列和发布/订阅这样更典型的企业技术被用到的地方，在许多情况下，把消息系统封包进API也更容易消费。

API作为集成方案跟SOA和ESB相比较如何呢？

Brasil：SOA就是在企业范围内连接服务以实现重用并省钱。API是基于SOA搭建的，强调的是开发者的可用性和自服务，跟创建可用于企业内部和外部客、合作伙伴及开发者的新服务有关。SOA在这类用例方面做得不多。

ESB解决了部分API集成和SOA问题，但是API问题要多得多。比方说，在通过自服务让开发者消费者API更容易方面ESB什么也没有做，对于确保有安全记录的系统在移动互联网的使用上的安全方面也是袖手旁观，缺乏高流量管理，也没有先进的安全和威胁检测。

我们的读者告诉我们说变更管理是API管理的痛点。这造成了什么样的流程和技术问题？

Brail：API是API提供商与开发者之间的一个契约。任何契约都要清晰阐明什么地方有可能会变，以及开发者如何才能知道这些变更。在最常见的API形式—URI以及大多数开发者都理解的基于动词的形式中，一旦特定URI/动词组合出现在那里之后，在没有引起很大注意的情况下这种组合是不会消失的，也不会以不兼容的方式变更的。

要想让这种契约有效的关键在于好的测试。现在我们拥有了像Swagger这样的工具，可以让我们正式指定API的格式，而且也有越来越多的工具在市场上出现，可用这一数据来测试和验证API。没有API实现的持续测试，契约想保持有效是很难保证的。

设计和开发API时，选择数据格式（XML、JSON等）的最佳实践、规范以及错误后果分别是什么？

Brail：现在，我认为用JSON很难出问题。这几乎是任何语言都可以创建并进行解析的最容易的格式，因为它与大部分编程语言的预期如此接近，其解析又相当的快，并且可读性也够强。我认为95%的API应该坚持用JSON就行了。

记住，剩下的5%归结为那些对性能有极端要求的用例，以及那些代表着大量你往重用的知识资本的现有XML范式的用例。高速度交易又是对性能有极端要求的例子。我说的极端性能可不仅仅是每秒几千万的API调用。至于现有的XML范式例子，可以看看像FpML（金融产品标记语言）这样的标准，以及许多人花了许多时间试图建立一个共同的方式用XML去描述某些非常复杂的东西这样的情况。

开发者和架构师应该采取什么方法去设计API才能既在今天更有用并且也能在未来依旧可行？

Brail：有些情况下超媒体（把超文本链接延伸到包括对任何一组多媒体对象的链接）会非常有效。如果API提供商及开发者相互理解得好，并且就约定和契约大成一致，那么超媒体驱动的API就可以成为健壮有效用户体验的基础—可以让API提供商实时调整来改变网络和市场条件，与传统Web应用可以根据用户分析加以改变的方式一样。我不认为我们将会看到基于超媒体的API会替代用描述得非常好的URI模式表示世界上的一切的想法，但是它会成为一个非常有效的编写移动应用的方式。

最后，我认为，就像Web用户浏览网页那样，我们可以增加可让客户端“浏览”API的超媒体链接，这种让更多传统API“可导航”的想法应该是更多API现在要做的事情。