Ian Robinson和Jim Webber谈论基于Web的整合

个人简介 本视频由马国耀翻译，黄璜审校。

Ian Robinson是ThoughtWorks的首席咨询师，他的专业领域是设计与交付面向服务的分布式系统。Jim Webber博士ThoughtWorks的全球架构主席，他与客户一起交付可靠的面向服务的系统。Ian和Jim目前正在合作创作一本关于Web友好的企业集成方面的书。

QCon全球企业开发大会（QCon Enterprise Software Development Conference）是由C4Media媒体集团InfoQ网站主办的全球顶级技术盛会，每年在伦敦、旧金山、北京、东京召开。自2007年3月份在伦敦召开首次举办以来，已经有包括金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

1. 欢迎大家参加伦敦的QCon2009，本场是对Ian Robinson和Jim Webber的采访。根据惯例，我们首先请二位作一个简单的自我介绍，Jim，你先来好吗？

JW：我是Jim Webber，在ThoughtWorks英国分部工作，目前，我正在和我的这位朋友Ian一起合写一本超级棒的关于使用Web进行整合方面的书。

IR：我叫Ian Robinson，我也在ThoughtWorks工作，是一名开发人员。 我从事分布式互联系统相关的工作。我也正和Jim一起合写一本书。希望我们说的是同一本书！

JW：嘿，你为什么不为大家多介绍一点那本非常棒的书呢？

   

2. 谈到你们提起的这本书，其书名是“基于Web的整合”。它和REST是一码事吗？能否简单介绍一下这个书名的含义吗？给我们来个电梯演说？

JW：当然，REST是REST狂热者的国度里最高祭司的象征，然而，不幸的是，我们还没有被这一教会所吸纳。我们使用“Web”的原因是它更具包容性，它包含了所有在广义的因特网上已被使用的技术。其中的一些可能不如REST那么让人愉悦、欢喜、那么好的性能、伸缩性或者合理性，但是这种特定的架构风格却非常有效 。我们更广泛地搜罗了网络中使用的有趣技术。

IR：我认为我们俩都不属于所谓的那种REST当权派(restauranteur本意餐馆老板)，某些人看到Jim站起来情绪激昂也许会作此感想，但是我们的方法更广泛。我们所做的工作是在月复一月的工作中寻找那些实用的解决问题的方法。

   

3. 我记得在几年前，当你提到REST的时，当时你很看起来的确有些怪异，人们不知道你在说什么，而在今天这明显变了。至少人们这些天谈论了很多，这些场次很收欢迎，大会进程排得也很密集。你认为目前人们在项目实施中采用REST的状态是怎样的呢？人们真用它了吗？

IR：是的，我们使用它。我们用的很多；或者我们所使用的基于Web的方法中有一些方法比其它方法更加RESTful。REST不一定要用在我们的所有工作中，相反，我们在一些客户项目中引入了一些轻量级的使用Web的方法，并且久而久之，就形成了我们的——某种类型的RESTful栈，在一开始把事物拆分成资源（resource）并对它们进行定位，然后进行连接，进而通过超媒体来驱动应用程序。的确，我们在许多领域看到了REST的采用。

JW：同意。我认为这是命运的大逆转（不知你们是否喜欢这个说法），从若干年前，那时REST几乎在任何严格传统的企业都会被嘲讽，而且即使是现在，客户将Web方式当做缺省的情况也并不乐观。事实上，我现在的客户，如果我们没有通过一些经验性实验而且找到了同样非常适合解决它们的问题的更为简单的Web方法时，它们就会认为大规模高性能系统就应该部署在传统的企业中间件上。有了那些实验数据，就对你有一些启发——诸如你会发现原来web方法在一个场景中能够用的很好，然后另一个场景，并且它会当你谈论分布式系统整合式它就能够成为你的缺省选择。

   

4. 这些就是RESTful化或者REST采用的不同程度吗（如果你也这么称呼它们的话）？当你向一个公司引进REST或基于Web的整合时也用这个方法吗？你的方法是不是从一点点REST的东西开始，然后越来越多逐步扩展？

JW：当然，我认为Lenard Richardson有一个非常很棒的尺度，一张RESTfulness级别的表格，用分贝或ROY，或其他我不知道的方式进行区分。Leonard把这张图标分成四个级别，从0级到3级，0级是最基础的转型，3级就是超媒体了，这也是我心中的理想模型。我并不愿意和人们分析这个模型，因为人们期望运用的技术是固定在“REST内部的”那些锲而不舍的人所做的工作。所以，在我设计和构建系统时，我会思考目标的适应性，而且我经常发现满足目标的东西往往出现在Leonard的那张图标的低端。它们对web感兴趣，却不一定对以超媒体为中心的服务感兴趣。

IR：我认为Leonard的模型实际上在我们与客户讨论REST时非常有用，因为客户会这样开始“解决任何问题，最简单的方式就是将它分解成一个个小问题。” 那我们做什么呢？——我们仅仅标识出资源并为其定位。因此，咋一听，他并非在谈论RESTful的东西，而是在谈论如何分解问题。继而他会说“如果我们要一次又一次地做相同的事情，那么我们就应该遵循统一的方式”——这就是他的第二个级别，仅仅使用了统一模型。

再然后，他第三次说的是“如果我们要做一些有意思或特别的事，那么就要以特别的方式来做”——这里才是与他谈论多媒体的时机。事实上，你可以跟客户，或其他人，只探讨那些将问题分解成块，相同的事情若要不断重复做则遵循相同的方式来做，然后必要时特殊对待。我认为这种交谈方式很好，进一步，还可以谈论一些特别的事物，如REST或使用Web，这样的交流方式很有效。

   

5. 你是否认为有些在人们看来是对HTTP的滥用的事情也是通往这个方向（采用REST和Web）的正确步伐呢？这些事情是你必须要做的，还是可以避免？你是否在某些情况下只能通过GET进行函数调用来改变事物，或者你根本无法辩护你的做法？

JW：在我里面有个愤怒的家伙，他往往藏得不太深，此刻它想跳出来撕碎你的脑袋，并坚信你的这些想法是多么地可恶。然而，在现实世界中，我们发现有些技术，如转换动词和URI，它们被使用在某些特定的上下文中，而有时的上下文并不那么的固定，这就比较危险。当然，在特定的上下文中，那些技术能帮助我快速把解决方案推向市场，我还是乐意使用的。

我承认这是一种粘合的聚类方法，而且我们常常回到过去并纠正错误。但是我认为，找到那种我喜欢称之“牛犇架构”的架构并设计出世界上最杰出的RESTful超媒体也许不是我们立刻就能做出来的。也许我们可以采用一些别扭的一点的步骤，比如转换（tunneling），从而让我们今天转起来，然后随着系统的慢慢扩展，随着需求的不段精细，随着它面对更多的系统，随着它受到更多的关注，我们就可以考虑（把现有的做法）移植到更符合RESTFul的模式，而新的模式是明确地符合那一类系统的。

IR：我们的确要探索大规模的基础设施。现在的事情能够成功的原因是因为Web已经在那儿了，而我们还需要开始接受Web的一些限制，一些随着Web的发展而带来的更多的限制。那些限制现在就存在，比如浏览器几乎只接受两种动词，GET和POST，还有，我们的解决方案常常不得不遵循哪些限制，而不论我们是否喜欢这种转换的方式。

JW：这适用于一些媒介——REST架构被膜拜，好像Web是一个完美的乌托邦，在这里所有事物都理解HTTP的统一接口的全部延展，而事实上并非如此。在Web上仅有少数几个演员，他们还不能理解某些动词，尽管HTTP认为他们真应该理解。这就是我们要考虑的限制，比如Mark Nottingham很喜欢跟我们讲的缓存成熟度曲线。

那些限制对我们来说的确是个挑战，因为Web的行为并不符合REST中所描述的它应该表现的行为，所以我们不得不采取某些实用的剪裁才能使系统运作起来。REST是有价值，而让系统转起来更有价值。

   

6. 事实上，我想Roy Fielding一定会非常赞同你的观点——HTTP和现在的Web并不是REST的最佳实现——他一直都是这么说的。

JW：很好，不然他的粉丝们会揍扁我的。

IR：不过，它还是很不错的。我们有一套自己方法。

   

7. 直到现在我才注意到我们一直在讲REST，却没想有对它作出解释。所以，也许有些人还不知道我们到底在谈论什么，你能否花一分钟的时间解释一下REST？

IR：它是“在Web上选择自己的路径去探索有趣的业务流程”。我们希望实现某些目标，让一些不同的事物协作起来，我们通过HTML或XML为客户和消费者提供服务，对于确定的一组目标“我想完成这个或那个”，它可以从选择一条通往服务器的路径开始，然后在服务器返回的表现中找到新的链接，就这样一步一步通往目标。

JW：这种说法的确很妙，我都想照搬它了，然而我还是要修改一下以让它看起来像是我的想法。可以这么说，服务器丢下一些面包屑给客户端并让他们跟上。它指引客户端沿着服务端实现的业务流程前进。我们倾向于使用一致的接口和HTTP的方式陷入这个沼泽，而所有的东西及其核心就是，服务端绅士般地牵着你的手带领你通过业务流程。

   

8. 你提到过有一些缺失，它们成了该基础设施的问题，比如浏览器在GET和POST方面的限制，然后是缓存、媒介和其他某些事物会忽视或阻塞某些方法。你认为目前在Web范围内还有其他缺失的东西吗？为有效使用它，是否有些东西是我们必须要有的呢？如果有，那会是什么呢？

JW：尽管Web本身是非常成熟的技术，目前最主要的问题依然是经验的缺失。我认为目前我们仅仅在学习如何驾驭它的某些特征然后进行系统整合。Web已经成为连接人与人的一种闪耀的机制，特别是在近几年，人们被带到网络中，通过pokes和tweet或其他类似的东西进行交互。

作为分布式系统工程师，我们仍缺乏某些在计算机之间协同完成工作的经验。例如，我们还没有找到如何在系统之间扩展超媒体的有效方法。就我而言，我认为这是我心中最关键的缺失。我很高兴周围有很多基础设施的怪癖和来自社区的不同声音，但是我想我们的确需要做一些实验并学会如何让它转起来。

IR：即便在客户端库中，也可以用一种相对通用和标准的方式访问超媒体。我正在想的问题是，我得到的返回是一个表象，可是我想要的是一个链接查询，它可以让我找到所有的超媒体，然后此刻我想访问哪个超媒体，我就可以为哪些关联该超媒体的URL进行解引用（dereference）。

   

9. 哪些场合适合使用REST和Web，而哪些地方又应该避免使用它们呢？

IR：只要你希望你的应用是真正可达的，那么就应该优先选择REST和Web的方式。对于任何要访问你的应用或与你的应用协同工作的人来说，它们的门槛相对比较低。然而，如果我们仅需在企业边界内运转的话，姑且不管这是不是一个好主意，那么我们就可以自由发挥了。如果我们永远不需要向任何人解释我们在做什么，我们甚至可以从头到尾发明一些新东西，但是当我们希望跨越任何组织边界的时候，我们就应该寻找一些足够精致的方式工作和协作，而不是只要能完成工作的最低要求即可。

JW：说得更远一点，当你考虑使用某种技术的时候，应该看看他们所表现出来的代价和优势。对于Web，我最喜欢提的问题是：“你愿意牺牲延迟并换来扩展性吗？”。Web的延迟不低，但是它提供了非常好的扩展性，特别是网络提供的协同工作。如果你能承受几秒、几分、或者可能是几小时，几周的延迟，那么Web的扩展性就非常棒了。

但是，如果你不能承受高延迟，那么再考虑Web的方案可能就是一个错误的选择。这时上帝会敲敲我的脑袋说，或许一些毫秒级或更少延迟的私有协议是你需要的方案。然而，我常常发现某些技术总是强调他们需要毫秒级的传输延迟，而往往没有真正根本上理解它们所面对的业务问题，而业务问题的要求可能是更为合理的几秒，在这种情况下Web就可能成为这合理的解决问题的低成本的方式。

像我们这样的电脑迷们承受着虚荣的极大折磨，因为我们总要求最酷、最快、最低延时、最优的系统节点，而Web却不关心这些。Web是“单调乏对味的前进能咋样就咋样”。如果不论何时都需要用延迟换取扩展性，或者说是扩展与高延迟并存，那就应该使用Web。

IR：我觉得这也是分布式系统开发的一个常见问题。它要求我们对延迟和不一致性多一点耐心。几个世纪以来，人们一直在致力于协调这些问题。假设我从一个城市策马奔向另一个城市，这个中间过程中就可能会发生不测。人们已经发明了能够处理这些问题的业务协议，而且，我认为这些工作推动了我们去关注它们并帮助这些协议语义再次浮出水面，而并非总是想着依赖于那些低延迟的技术并用它们来做所有的工作。

JW：这相当有趣，因为作为分布式平台的Web，它所强调的一定是分布式。从这么多年的计算机科学的发展来看，我们得到的教训是抽象是个极好的事物，而且，我们应该把所有艰难的计算科学的东西交由科学家们去处理，而在活跃快活的业务网站中忘却这些痛苦。实际上，你再也不会像多年前Waldo告诉我们的那样可怜地被计算社区所轻视，相反，如果你决定使用基于Web的分布式系统，Web不会向你隐瞒分布式，而是给你一些有用的信息去协调分布式交互，再举个例子来说吧，用信马（messenger-horse）打个比方，当你的马在高速公路上被某个警察抓住时，你可以采取合适的行动去挽回。作为过去的事务追求者，我看到的Web是一个庞大的协作平台——两阶段同意的事务会让人发疯。

IR：刚从你不能上帝的眼睛去观察自己的成功的失落中缓过来了吧。

JW：离Tim大师远一点……他可以随时看到整个Web。我不是开玩笑哦，你发一篇博客，他是知道的，他正看这你呢，他正通过一个网络摄像机监视着你呢。

   

10. 正好你提到事务，我听到关于REST的最多的批评之一就是它缺少很多企业级的特征。使用Web服务时，你能使用一些事务相关的协议，提供原子性事务的WS-Coordination以及WS-Business Activity等等。你认为这是一种缺陷吗？我们使用基于HTTP的REST时需要一事务相关的协议吗？

JW：不，下一个问题吧，我不赞同这种说法。我认为我们正在学习Web提供的处理事务的方式，经典的两阶段事务实际上并不适用。任何听过Gregor Hohpe谈论最终一致性（eventual consistency）、读过Gregor Hohpe写的关于Starbucks为何不使用两阶段提交的文字、任何真正对这个问题有过即使是转瞬即逝的思考的人都会理解两阶段事务无法用在Web上。你是在用一致性换取扩展性，而Web着眼与扩展性，潜在地支持最终一致性的技术。

我不是公然宣传我的书，其实在这本书的第12章有相关的讨论。实际上，现在我们已经煎熬地完成到第11章了，我们努力雕刻那些章节以至于可以跟上Stefan多产的步伐，他正在写一本等同的德语版的书。我们实际上很煎熬，如果你们愿意听，我们为了安全、事务、消息可靠性等方面使用了WS-*的技术。 我们在简单古老的Web的HTTP世界里展示了等价的模式和策略。我们并不宣称我们的方法是RESTFul的，拿事务打比方，我们只说你并不真正需要它，因为Web会给无时无刻不在为你提供这种协作。

作为一种同步的逐步推进式基于文本的协议，Web不应该立足于全局范围的[事务]，这似乎有悖常理，然而这是事实，因为在每此关于某个Web上资源的交互，我会得到一些元数据，它告诉我这次交互是否成功。因此，我可能选择继续冒险的路径——如果我愿意的话——这样我会继续访问后续的资源并往前走，或者因为该元数据传递给我的信息是我正在进行的事情可能失败，我也可能通过一组已链接的资源走后其他流程走向另一条路径，这就是另一种前进方式。对我来说，这才是处理意外输出的更合理的解决方式，尽量把所有的事情包装在Web的更大的事务中。

IR：“你面对的是一个拿着斧头的侏儒，你会怎么用他？” 我的意思是，即使有WS-*协议，我也不认为我们在任何情况下都要把它用在有许多服务参与的事务语义之间的协作。虽然我们跨越Web以RESTFul的方式把服务的内部实现暴露出来，但是也许你真正要用的却是在粗粒度的边界背后的内部实现，它们可能依赖于一些更底层的协议。我认为这没有错。如果我们已经准备好承受锁住许多资源的代价，我们正在寻求一种粗粒度的边界，而事实上在这个层次上我们不一 定需要它。

JW：那也是有代价的，对吧？这一定需要更灵活的设计才能保证正确，因为在最底层，如果你正在使用的是一种遗留的关系型数据库，你就要必须考虑这 些事情——是的，我这么说过而且也一直这么做的——但是你一定要明确地设计出来，而且要小心对待那些容易被无意中忽略的细节的抽象边界。如果你的失误走漏到Web中，你就搞砸了。

IR：一旦你把后门钥匙给了某人，他将来就会从后门进入你的房间。

   

11. 现在我们已经讨论了事务，那么你觉得在REST中加入类似BPM/BPEL的东西怎样呢？你认为我们需要这样的东西吗？

JW：Web的链接不是已经提供了这样的功能了吗？:) Web有这样的免费的编排功能。

   

12. 是吗？我不好确定。这是个真诚的问题，我指的是引擎……姑且不管它是使用哪种语言编写的，但那些引擎可以处理这样的事情，它们可以将不同的请求搭配到不同系统中，而响应是异步返回的，它们又将这些响应搭配回原请求并做其他工作。这听起来是个很有价值的功能，难道RESTFul的世界不需要类似的能力吗？

JW：的确很有价值。从得知特定的输入得到什么输出这个角度来看，使用某些规则来实现也是很好的。而只有把它捆在让人恼火的BPM语言一起使用时，才会让我不爽，原因是在使用时有很多负担。我们看到过很多可以通过点选方式建模的BPM产品，而使用他们时我们往往发狂，这是因为用它们很危险。 使用Web时最困难的事情就是让客户端协作起来。如果我们可以解决该问题，那么Web将是更容易驾驭的方案，但是我完全同意我们需要客户端协作，可我并不认为一定要我们今天所看到相同的产品线和解决方案。而类似于Prolog或规则引擎，也许是实际上处理和编排Web上的处理的更好的方式。

IR：这是一个客户端或服务端的内部实现的问题，不管他们在交互中扮演的是什么角色。按你的说法，为了实现一个目标可能需要一步接着一步最后达到目标，这也是无可厚非的。而如果服务端返回给你的是一个表象，它为你提供了一组选择，你可以应用某些智能的方法去选择你的路径，这也反映了一种带外（out of band ）机制，这样我们也能像你所预期的那样交互。它提供某种标准的合理的食物的解释方式，如“rel”属性等。

JW：这种带外只能可以是一种微格式（Microformat），而且可能应该是，因为他们轻便而生动。

IR：是的，但是很多流程都是很简单的，顺序的，或者由事件驱动的。用最简单的方式去实现它们相对比较简单，而且没有必要非要依赖于规则引擎或某些工作流引擎等工具。

   

13. 让我们谈一些切实的东西吧，我们已经谈了很多理论方面的好处，所以现在我们谈谈实际的。对于那些接受了REST的人们，他们想搞点RESTful的东西，你推荐哪些工具？从我们已有的不同的技术领域，你在构建HTTP上的RESTful系统时最喜欢用什么工具？

JW：我承认我最喜欢的都是简单的工具。目前我正在做的是一些非常高性能的系统，用的是Java，它挺好。当然，即便是Java，我们也有很多选择， 我们可以选择Restlet，也可以选择JAX-RS服务端实现，二者都是非常完善的框架，提供了很多的工具。在这种情况下，我们使用servlet，因为他们已经足够我们以一种轻便的方式完成工作。相反，比方说如果你在使用.NET平台，那你就能用WCF中的WebInvoke和WebGet等工具，或者你也可以仅仅使用HTTP句柄（handler）。

IR：或者也可以是HTTP监听器，实际上在自托管的HTTP中WCF使用的就是它。你也可以使用它，而且，在其之上写程序相当简单。

JW：更狡猾的回答是你自己做主。如果你喜欢使用高度抽象的框架，如WCF或这JAX-RS，如果与驾驭像servlet这样极度以HTTP请求/响应为中心的事物相比，你觉得把这些框架放在你的应用域中你感到更轻松，那你就这么用。用你认为最舒服的工具就好！

IR：我一直不断探索的一件事情是，如何在应用协议的周边进行交互，我喜欢用测试的方式来做。测试是很有用的一种文档方式。我想通过应用协议向你描述你可以通过什么方法让我的服务作出反应。比如，如果你想这个端点提交这个表象，调用这个方法，你就可能获得这中表象的返回，这种媒体类型，这些状态码 ，这个HTTP头。所有这些只是应用协议的一部分，我们是在与自己建立某些微不足道的合约。比如，你可以在AtomPub规范中看到很多这类的东西。

我喜欢做的事情是把所有的断言都放在一个测试中。我常常在探索，能否不需要每次都开启一个服务实例，或者不需要通过线上的交互，就能完成测试。因此我常常在寻找一种非常轻量级的抽象，这样我就可以在不需要启动服务的实例就能为所有的HTTP构件创建测试预期。我记得你曾用Spring中的模拟上下文（mock context）干过这事。

JW：通过sevlet和一些Spring的模拟的确是一个很好的方式，你不需要等待20个小时等待Tomcat完全把服务启动，的确很轻便，很实用。

IR：而我偶尔做的是创建一层很轻薄的封皮（ wrappers ）把请求和响应封装起来。我能使用它们独立地代理任何我使用的运行时，然后，我基本就可以写一些测试程序去测试它们，或者模拟那些请求和响应的实例。

   

14. 你们提到了“契约”这个词。你们怎么看待REST相关的契约？因为在Web服务的世界里，契约的确是所有事物的核心。据我所知，Jim是那些极棒的WSDL 描述文件的狂热粉丝之一，它真正非常正式，非常完全地描述了服务所暴露的方法。你们根据什么去和一个没有正式描述的服务进行交互呢？没有WSDL文件，你们是第怎么工作的呢？

JW：你可以有一个非正式的描述，然后就会有一大批Ian的绝妙的客户驱动的契约。

IR：我常常认为媒体类型（media type）表达了一些契约信息，从它身上你可以得知将返回给你的是那种表象。更加有趣的媒体类型实际上也包含了很多那些与协议相关的规则。还有，我觉得像AtomPub这样的，它不仅告诉你，你将得到什么返回，而且他还会告诉你，你能访问哪些方法以及调用这些方法将得到状态码。这里是有协议的，他们只是被传来传去，而且我认为我们应该探索媒体类型，它们能清楚地告诉我们：我们能做什么，我们能怎么查询和浏览这些超媒体表象，以及它是如何将我们同超媒体联系起来推进应用的。

   

15. 可以说是超媒体格式承担了契约的角色吗？

JW：没错，笼统地说，是这样的。事实上，我们的一个朋友，也是过去的同事，George Malamidis曾对我说过：“Web已有一种契约语言，它叫HTML。” 直 到今天当我说这句话的时候我还是很害怕。George是这些圈子里面非常深邃的思想者，但是我还是相信他是对的，我只是害怕一下子站到他的高度。

   

16. 让我们假设你已经说服了某人，REST是个好东西，但是现在轮到他们去说服他们的同事去实际使用它，你有和建议？你在你们公司是如何宣扬REST的呢？最好的方法是什么 ？

JW：我不会宣传它。我认为它必须作为某个环境中解决访问的方法出现。大概在去年左右，我曾参与过一个系统，该系统最初的设计是基于JMS的。这很好，我也喜欢用JMS ，它是一个很好的想法，但是最初的设计是在没有整体考虑该系统将要部署的环境下完成的。JMS虽然很好，但也有它的复杂性。最后通过用几天的时间完成的一个桩，我们发现实 际上该系统所要求的负载是HTTP就足够胜任的。

从我们不断改进软件交付的角度说，HTTP具有很多的好处：它要快得多；较之JMS，写HTTP程序要简单得多；你可以容易地使用类似于Poster或者Curl这样的工具进行测试。当时那的个系统的交付非常好，房间后面的一个人开心地笑了，他也是我们中的一员，HTTP的确很棒。而且，我想如果当初我们沿着JMS的方向走下去的话，那我们会辛苦很多。事实是，QA 人员可以用带有Poster插件的Firefox对该系统进行测试，或者是一些高级的容易理解的探索性测试，他们以我们没有相像到的非常好的方式破坏我们的系统，因为系统表面对他们是开放的。这让我很开心！

IR：最后赢得到更多的支持者，对吧？

JW：是的，所以这又是一个有影响的事情。

IR：很多人对于系统如何运行，或者系统如何向外界暴露服务都有自己显见的理解，并且人们习惯于使用自己所熟悉的方式去查看，比如浏览器，Poster或类似的东西。这非常奇妙：事实上，我们也是从我们所喜欢的东西开始，我们更喜欢谈论Web，Web相关的事物以及REST，进而更多地谈论REST，我认为在一个组织里宣传REST有时并不合适。我常常在人们说“我要SOA”时就非常崩溃。SOA是另一个应该被删除的单词之一。我们的谈话应该从我们要做什么开始，并且用人们所熟悉的方式去讨论它，而现在不熟悉Web的人几乎没有了 。我们可以仅仅从一些Web可以做的简单的事情开始，并说“想想，你的应用是不是也能这样工作呢？”

JW：SOA的危险之一就是它经常和产品绑在了一起，以至于常常变成“我可以卖给你SOA”——“不，你不能”，而且我看到REST的名字也使用到某些软件产品之中了。这有时候给人们的谈话带来疑惑，因为人们想他们可以将REST插入到他们的应用之中，他们可以购买REST平台，然后就变得RESTful了，然后，他们做的所有的事情就认为“包含REST”了。他们不会批判地思考它（REST）为什么对业务有帮助。这仅仅是高级IT决策者或者提供商们的结论，而不一定是出于对业务最好的角度，而且几乎不会出于开发团队的角度考虑，而开发团队才是实现服务的真正主体。

IR：通过插入某种适配器就可以将一个WS-*的应用程序从外表上包装成一个RESTFul的应用，还希望它能成为一个丰富有用的RESTFul的应用，这几乎是不可能的。

JW：这样的应用是一个危险的REST应用，因为其底层实现的设计就没有这样一层表面或以这种方式加载，因为其底层实现是以消息为中心或RPC的方式设计的。

IR：这区别大了去了，而且从其本身思考，假设在一个资源之上套上一个更大的资源，而这个更大的资源是在一个完全不同的泛型中设计的。你就会失去发现业务及流程的有趣点的机会。谈到资源，它常常展现了事物内在的固有价值。搜索结果的进进出出对于Google这样的公司非常有价值，这就是他们用来挣钱的方式之一，把搜索结果展现成资源是思考和探讨的一种很好的手段。

   

17. 观众提问：REES位于HTTP之上，HTTP是一种非常古老的规范了，我们使用它也已经有很多年了，有没有可能REST会后退到HTTP规范所规定的范围之内呢，不论在过去的20年内我们是如何使用HTTP的，现在我们是以更有趣的方式在使用HTTP了，而且，我们仍然有一些没有完全实现HTTP规范的客户端或浏览器。比如，大家都知道，将FLEX和REST用在一起非常困难，那是相当恐怖！你是如何看待的呢？你是否觉得我们应该需要一个新的规范，或这更新，这样我们才可以解决哪些我们以前使用HTTP时没有碰到过的哪些问题，也许现在我们需要更多的HTTP能力？或者，你是否认为在将来的1-2年内所有的浏览器会实现当前的1.1规范供我们在未来的20年愉快地使用呢？

JW：浏览器不支持所有的HTTP动词的原因主要是HTML不支持，所以我们留下了GET和POST，这是非常有限的。我并担心，原因是对我而言浏览器已死。它是最常使用但却是最没意思的Web代理。我更感兴趣的是计算机间的交互，而不是人和浏览器之间的交互，而且现在，在人们对它（浏览器）施压时，它已经嘎吱嘎吱苟延残喘了，但是对于人们互相 facebook或做任何小孩子们做的事情来说，它还是能足够胜任的，所以我并不担心它。真正让我担心的是W3C中的一些工作组正在前进的一些未来方向，它们将更有效地重织网络。 现在的Web基础设施，在世界的各个角落都可以访问，它也走到了自己的神奇的临界点（tipping point）。

我担心如何W3C的伙计们会带来一个新东西，比如HTML5.0并将它推广开来，那就会出现一个怪异的悖论——网络中一半是原有的Web，另一半是新的，他们各自拥有Web套接字，而 且都很困惑，网络中不在只有扩展标记语言，这是我想到的最大的麻烦。目前，我正在等待浏览器提供商的创新，我没有什么意见，对此我没有什么兴趣，但也觉得尚可。我希望 W3c能以更加发展的方式来滋润网络，而并不希望看到某人成为Tim先生（万维网之父）第二，不幸的是，我担心W3C中可能有人会想这么干。

   

18. 观众提问：最近我们看到，即使在现在的大会上，在编程上，很久以前我们有了Lisp，然后我们有了更多的抽象以及对象或更大的组件，现在我们看到人们又回到了函数式 编程上了。Web中也发生着类似的事情，我们曾有简单的HTTP规范，然后我们又有了很多抽象，如SOAP和BPEL，然后我们又回归简单，到了REST。这是否意味这一种走向简单的趋势 呢？又或者这是软件一直以来的方式，风水轮流转？

JW：回答这个问题我还不够资格，呵呵。Ian经历过多次这样的轮回，所以他应该有合适的答案。

IR：从怀旧驱动的发展的观点看，每个文字开始时就很好，回到古老的方式并没有什么不好。你谈到了简单性和趋向简单性的趋势，我觉得对于REST推行者来说，在推行的时候， 简单性并不是他们要强调的优点，而是限制，让限制再次浮出水面并意识到他们。围绕这Web有很多应用，而这些应用往往滥用了Web的基础设施及其使用方式。好的REST推行者会 强调和展现哪些限制并告诉你，如果你在这些限制之内工作，你就可能实现更可达，高性能。这是我钟爱的回答。

JW：是的。我们的确为分布式系统做了一层又一层的抽象，但是你知道吗？这些抽象并没有带来什么好处。世界上一些最大最复杂的分布式系统并没有那么大和那么复杂，然后这 些蹩脚的协议出现了，它们强调同步，强调文本驱动并且全球范围内推广。这让我们工程师们很惊诧而且觉得没意义。这是Web的悖论：这是世界上最垃圾的东西，但是很广泛。对 于我来说这已经是尽头了，因为我们是完全支持基于XML的协议并且干的都是这类时髦的事情。

我把我的名字放在一些OASIS的项目以及其他事情上——希望上帝会阻止坏事的发生——公平地说，我们认为我们有最佳的意图，我们认为这些东西会有用，并且在某个特定领 域内有用，但是Web和HTTP已经向我们证明了，如果你要扩展和广泛可达，你必须要做一些简单的事情。这些简单的协议是让每个人能够交互并且让这种交互能成为21世纪早期计算 领域的核心的基准线。所以，没错，回到根本！