根据Programmable Web的数据，73%的API都是RESTful的，因此有些人过早地得出了这样的结论——REST已经赢得了胜利。但SOA从业者Steve Jones却指出使用这些API的都是用于数据聚合的前端系统，大多数企业系统并没有使用，因此REST尚未成功进军企业。
\Mashery的前CTO Clay Loveless在Glue Con 2011上作了题为“Lessons from the Failure of SOAP”的演讲，与大家分享了来自于Programmable Web（一个API资源索引器）的一些统计数据，数据表明SOAP在过去几年间已经有了长足的进步，但其份额还是要小于REST，而REST则处于平稳发展当中：
\\\
\\\
针对这些数据，SOA从业者及Capgemini数据管理部门的全球总监Steve Jones说到，他们并不能准确表示出现如今REST/SOAP的使用情况，因为Programmable Web并没有收集企业数据：
\那么对于Oracle、SAP、IBM或微软的企业技术栈的调查结果是怎样的呢？我认为其基数相当大，并且有很多已经用在实际产品当中了，其基数为 2368，够多了吧？我曾经呆过的公司的SOAP端点数比这还要多。如果将SAP、Oracle以及 Oracle AIA Behemoth的WSDL库也考虑进来，那么数量就更多了，Oracle对此并没有过分宣扬，因为已经够复杂了。回到2005年，那时Oracle曾宣称他们的应用使用了3000个Web Services。\
对于REST与SOAP之间的论战，来自于ReadWriteWeb的编辑Alex Williams在Glue Con上报道说SOAP并没有死，而是“会继续存在一段时间”，因为SOAP扎根于企业，我们很难轻易地摆脱掉它。
\Jones对Williams的文章发表了评论，他说SOAP还会继续存活于企业，而REST则是刚刚破茧而出：
\SOAP并没有死，它依然在企业中得到了广泛的应用，事实上，在集成各个厂商（大量的企业IT）的解决方案时，SOAP依旧是唯一可靠的方式。\\面向企业的REST则刚刚破茧而出，它至少还需要5年的时间才能发展起来。
此外，Jones又发表了一篇文章，谈到过去一年中，REST在企业集成与治理方面并没有取得多少进展，原因在于发布、版本化及测试上：
\首先说明一点，我这里所说的REST指的是一种企业集成方法，而非为了内容聚合而实现的一种Web API的公开方式，它是一种面向企业的功能性集成方法。REST要比“缺陷多多”的WS-*好多了。那么它今年的发展势头如何呢？有一些小公司涌入了企业栈，声称他们可以创建REST接口，但实际上大多数都做不到这一点，因为接口发布、版本化及测试等关键问题尚未得到解决。\
InfoQ有幸采访到了Programmable Web的创建者Clay Loveless与John Musser以期了解他们对Jones关于企业与REST文章的看法。
\他们也认为SOAP还将在企业中存活一段时间，但REST终将取胜：
\我认为Steve Jones说得很对，我之前也曾说过：SOAP还将存在很长一段时间，特别是在企业中。\\企业对变化的反应速度很慢，很大程度上都是由厂商——消费者之间的关系所驱动的。如果企业的中层管理人员不能把钱花在支持合同上，那么他们就会觉得自己的工作没做好。
\企业在商业空间上总是落后一步，过去是，将来也是。在B2C世界中，REST已经赢取了胜利，John的[Musser]数字已经证明了这一点。当公司认识到他们无法在SOA职位上招聘到合适的人选时，他们就会使用REST进行快速且代价更低的构建，这时变化就产生了。这种情况一时半会还不会出现，但迟早会出现。与之类似，印刷机与黑莓都在走向没落，但这两个领域的人们却都在极力否认这一事实。
Musser曾在Glue Con 2011上就API的现状发表过一次演讲，展示了与上图中相同的数据，他坚信趋势是不可避免的，REST最终将会征服企业：
\我同意Steve与Clay的观点，SOAP API在企业中还将存在相当长的一段时间。主要的推动力可能是REST与SOAP的技术方向，无论是技术上的原因还是CIO拍脑袋想出来的，最终都是由职责所推进的。Steve认为现在有大量应用和企业工具还在使用SOAP与WS-*技术。\\我在上周演讲中所说的是如果回到2005年，那时SOAP在基于Web的API中风头很强劲，但再看看从那时起到现在的6年间，你会清楚地发现REST所占的市场份额越来越大。这里所要表述的并不是目前实现或端点的总数，而是发展趋势。看看面向企业的厂商在关注什么，你会发现是REST。当然了，他们并不是要放弃SOAP，看看Salesforce.com吧（在过去长达10年的时间内，他们一直在使用SOAP，但现在却在使用REST或是微软的Azure平台）。
我们还采访了Steve Jones以深入了解他认为REST尚不适合于企业的原因。
\InfoQ：你说过在过去一年当中，REST在EA集成领域没有取得丝毫的进展，依据是什么呢？有具体的数字么？这个结论是否是根据你所在的企业而得出的呢？
\SJ：我看到REST在企业中有了一点儿发展，但这一切都是在Web端而非企业系统间的内部集成。我的结论也是根据Programmable Web的数据得出的，其中一个例子就是SAP链接（https://streamwork.com/developers），这实际上是个REST API，用于REST领域当中。前端集成与聚合。
\Programmable Web列出了不到2500个API，其中来自于SAP的只有一个，Oracle则一个都没有。这表明REST社区根本就没有意识到企业集成的现实及其面临的挑战。
\InfoQ：你提到了REST在内容聚合上的发展，但却说REST在EA集成上并没有取得多少进步。能否谈谈这两个领域间的差别么？我们该如何做才能让REST适用于EA？接口发布与版本化么？
\SJ：数据与功能。如果我想在一个页面上查看5个不同系统中的所有账户时，那么REST就是最适合的方式（只要通过MDM方案能在每个系统中识别出客户的键就可以）。但如果我要打开5个账户、将其传递给计费系统，然后让团队能够独立处理他们（这是关键），那么REST就不适合了。
\企业集成要处理的是将各个领域分离开来，然后通过定义良好的边界让其能够独立运作。这些边界常常是通过外包，或是通过厂商的分包实现的。REST的本质要求这些边界是不固定的，如果将其固定起来就会出现问题，现实情况是固定的边界是一件好事，因为它能让团队独立工作。因此，发布功能性契约（WSDL）的能力就是SOAP/WS-*的核心优势，这些契约可以被多种技术栈所使用。
\对于REST与MDM来说，它本身就能很好地说明边界。REST需要从多个系统中聚合关于同一个消费者的信息。“真正的”REST方式会有一个中央消费者系统，所有人都通过一个URI来使用它，这就是唯一的ID。现实情况是SAP与Oracle等系统总会保留消费者信息的本地副本，因此我们需要使用某种形式的功能集成与信息同步。这正是WS-*的用武之地，因为它提供了一种方式来“创建用户”并且可以返回“同步消费者”。
\从纯技术角度来看，关于SOAP与REST之间差别的讨论并没有意义（http://service-architecture.blogspot.com/2006/05/soap-v-rest-more-pointless-than-vi-v.html、http://service-architecture.blogspot.com/2006/09/why-rest-v-ws-is-irrelevant-in-two.html），现实情况是企业需要集成的是发布契约的能力，这种契约不仅要从技术角度能够使用，而且人类也应该知道如何调用它。WSDL虽然有种种弊端，但在这一点上要比REST简单。
\企业集成的现实是采取的方法（入MDM）要比具体的技术在集成的复杂度与灵活性上有着更大的影响。
\InfoQ：你认为REST的未来将会怎样？
\SJ：现在天花乱坠的宣传太多了，很多人都在抱怨其他人并不“知晓REST的真谛”，但却忽略了REST的缺陷。我希望REST的拥趸们能够醒醒，并就描述REST的功能接口的标准方式上达成一致（http://service-architecture.blogspot.com/2010/01/define-standards-first.html），这是最基本的事情，但很多人却吵着说这违背了REST的原则。或许问题在于REST从根本上来说是关于数据遍历与聚合的，它并不适合于面向功能的方式。
\InfoQ：如果不采取REST，同时SOAP又因为其复杂性而饱受诟病，那么EA集成的未来会怎样呢？
\SJ：企业集成非常复杂。它要比人们所能想象得到的Web集成还要复杂，因为他们需要高性能。速度并不等于性能。企业集成非常复杂，但却与REST和SOAP之间的技术差异没有多少关系，对于企业开发者来说，REST更加复杂，因为它无法通过标准的方式来定义功能接口。
\改进企业与B2B集成的方法是向这些接口添加更多的形式，这样就会减少文档各自为政的情况。举个例子，指定出生日期时要限定在某个日期之后，在打开账户前需要进行信用检查，这都会起到很大的帮助作用。
\批评B2B与企业集成中SOAP过于复杂的人忽略了这样一个事实——复杂源于何处。复杂来自于你需要集成多个不同的业务领域，同时又缺少标准的核心业务以及技术方法（比如MDM）。技术方法只不过用于在网络上传输XML，而相对于旧有的方法来说，SOAP已经大大简化了这一点，因此它实际上是降低了复杂性。REST并没有做到这一点，因此并未得到使用。
\Jones又在Twitter上说到“mosesjones：我可能错了，REST最终将会赢得企业市场，但REST拥趸们需要更加实际一些，而不是单单从技术角度看待问题”。
\你有何经验？REST适合你的企业么？你是否解决了Jones提到的那些问题了么？你觉得REST会在未来的企业市场中抢占SOAP的宝座么？
\此文在InfoQ英文站发布以后引来众多读者的评论，现摘取其中几位读者的评论，也许他们的想法与您不谋而合。
\读者Steve Jones说到：
\\t我认为Clay所说的企业对变化的反应速度过慢是不正确的。SOAP/WS从人们眼中的救世主到成为事实上的企业集成方式经历了4年时间。REST的拥趸们喜欢假设企业的反应速度过慢、笨重、甚至有点儿蠢，但现实情况却是当一项技术可行，它的传播速度会非常快，这也能够说明为何WS-RM、WS-Security以及其他的WS-*只用了几年时间就普及了。企业的脚步很快，厂商的脚步也很快，这意味着工具、自动化、测试与安全产品的发展速度都是非常迅捷的。 \t\\相比之下，过去5年间，REST领域只新增了很少几个API，很多还是来自于企业级厂商，但没几个是标准，更不必说元类型了，REST的工具与自动化更是一片空白。
\或许REST会取得胜利，但在企业集成项目中，我的经验是SOAP仍将会完全统治MQ Series和其他基于消息的方案，REST或许会成为继ETL之后的第4个解决方案。
读者Faisal Waris说到：
\无契约风格的REST实际上根本就不存在，我们现在使用的是具有隐式契约的Web API（但没有元数据来描述服务接口）。\\服务端与服务端之间的交互通常都是基于WS*的，因为工具可以轻松处理基于WSDL的服务接口。浏览器与服务器之间的交互最终都是通过HTTP进行的。
\后端使用SOAP实际上是有多种原因的。比如说，发布——订阅以及通过ESB一XML网关实现的异步消息、使用了WS-Security的B2B消息等。企业开发者似乎更喜欢使用XML Schema（以灵活性作为代价）描述服务接口。
读者Gerald Loeffler说到：
\这些观点与我在集成项目中的经历完全吻合——看到这些我感觉一下子放松了不少，我在想自己所经历的这一切是不是具有代表性。\\然而，文中所述的“SOAP与REST之间差别”的“纯技术视角”并不是“无意义的争论”：虽然现在看来这种争论有些过时，但如果不基于纯技术进行比较，那么我们就会失去任何技术领域都需要的严谨。当然了，除了“纯技术视角外”还有其他很多内容值得讨论，但我总觉得“架构风格”与“业务接口”这两个概念已经对此强调很多了。Jones所倡导的是根据业界的使用情况来判断“成功”抑或“失败”，并且借此寻找“失败”的原因（比如缺少精确的接口定义语言，如WSDL）。
\此外，Jones提到“人们抱怨其他人并不知晓REST的真谛”，这得出了这样一个事实：当人们以一种方式全神贯注地观察世界时（这叫做意识形态，比如WS-*与REST，抑或静态类型与动态类型），他们不可避免地就会将其看作是真理。但事实并非如此：这只不过是观察世界的一种方式而已。但遗憾的是，在软件开发中，某些人所宣扬的真理通常要通过侮辱其对手来实现，就好比“并不知晓REST的真谛”这句。
读者Dave Duggal说到：
\没有银弹。我们在基于一个图形模型进行开发，使用RESTful调用（HTTP作为传输层）协议（本身是资源）以在运行期通过传进与传出的上下文来修剪图形。\
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
