问：如果我认为REST值得一用，如何才能在一个小组组合中识别REST设计/开发机会呢？

　　答：简单的回答是尽可能的使用它，但是实际情况往往没有那么简单。

　　如果你正在设计并开发一个新型、可扩缩Web应用，REST无疑是最佳选择，如果是在现有企业应用的扩展上进行工作，或者在一个完全依靠抑或是部分依靠现有基础设施的集成项目上工作，在决策时就更加困难了。和重用现有应用相比，如果你要开发并设计一个新Web应用，对于REST方法的要求就显得更为紧迫了。

　　这里需要指出REST和REST/HTTP之间的区别，REST是一种可以用任何技术实施的架构模式，而REST/HTTP则是一种REST架构实施。人们谈论REST时，实际上说的是REST，但是我想澄清一点（出于这个原因，在讨论“事务处理原则”第二版本的可扩缩Web服务器时，我们指的是REST）

　　总的来说，当初是为了自动化内部业务操作才设计IT系统的。至少到Web出现，一直都是这样。后来则是为了在Web浏览器外部访问业务操作才设计IT系统。

　　在2007年10月召开的高性能事物处理(HPTS)大会上，与会者展示了全部大型网站(Google、eBay、PayPal、SecondLife、SalesForce等等)而听众则向TP监视器开发商和发明者展示了应用服务器和关系数据库产品。那些Web工作者告诉从事数据库和TP工作人员，许多企业发现他们使用了三十几年的产品实际上根本无法满足自己的需求，只有自定义解决方案才能保证REST/HTTP的成功实施。对于使用REST/HTTP，大型网站的要求和内部IT系统的要求是完全不同的，在内部IT系统中传统的软件产品通常无法很好的满足需求。

　　大型网站的成功很大程度上证明了REST架构模式在HTTP上发挥的功效。但是同时也表明了当代软件产品的不足，并预测大型分布式计算系统的诞生。未来的几年里，将会不断涌现新的产品设计，目前缓存管理方面就出现了好多新产品。

　　不过，如果你想在网站基础设施中寻找一个普遍模式，到目前为止这种模式还没有出现。因为每个人从事的工作是不一样的。这就意味着如果要创建新的方式来实施大型应用或者设计新型产品，需要花费大量时间。

　　我清楚的记得几年前，一家电信管理论坛不停地赞美基于网络的业务模型（例如无人售货，通信成本低廉以及容易开发），但是最后却又抱怨现有的电信公司很难在网上进行业务操作，因为他们的“antediluvian后台系统”

　　概括的讲，你陷入了一种困境，网络技术和REST/HTTP方法，在许多大型的极为苛刻的环境下都显示出了良好的运行状况，并带来了高额的收益。但是，如果你现有的系统不是为了网络所专门设计的，这样一来，架构的不匹配可能需要投入过多的资金。

　　有时投资是合理的，或者能够带来丰厚的收益。有时，扩展并重用现有的基础设施可能更符合成本效益。有时，将REST/HTTP混合在一起使用可能更为有效。

　　直到可扩缩网络世界产生普遍模式—目前已初见端倪—REST/HTTP方法则需要许多自定义代码，并通过现有的企业软件产品，寻求功能和特征的平衡。采用REST/HTTP方法的益处是非常明显的，但是，实施这一方法的成本/收益前景却不那么明显。