基于web服务和不相关协议的实现来创建灵活的、松散耦合的解决方案，是现代企业设计的基石，但在这一理论之下充斥着大量的异议，引起不少争论：对于软件开发来说，是面向服务方法最好，还是面向资源的方法最好。每一个IT专业人士都应该了解这种方法的不同，这一点很重要，以及了解什么时候其中一种会优于另一种。

　　十年前，面向服务架构（SOA）横空出世，出现在IT舞台上。自那时，SOA已经向业务交付了很多价值。它把流程和程序分配成更可管理的部门，这帮助解决了企业应用套件面临的一些碎片问题，使之更易集成。例如，SOA方法使打包现有遗留资产成为可能，不必重新创建旧的应用就可以现代化。在跨整个场景中，SOA通过提升和支持服务重用使开发和管理方面受益匪浅。

　　SOA益处：MIA

　　对于SOA抱持不满意态度的人在过去的几年中已经上升到咆哮的程度了。据LessAccounting的StevenBristol所说，“面向服务架构是对可扩展性精华的提取、是更易管理的代码、是依功能划分的业务逻辑的一部分。因为在你开始时你不能看到所有地结果，你只能猜测事情将会如何。”因为你可以想象，有根据地猜测和盲目的想象之间的区别在架构师们遇到的问题中占了大部分。

　　就因为这一特殊解决方案适用于大量的问题，业务人员就会学习它，它不能回答所有的事情？业务人员面临的一个问题是，当他们应该依靠其它东西时，他们却在试图使用SOA。MattBrasier说这是一个常见的错误。他是C2B2咨询部门的头，以及《OracleSOA套件11g性能食谱》的联合作者。业务人员把SOA当作所有IT症状的灵丹妙药，最终的结果一定会让他们失望。过去的几年里，在为了API部署的基于服务的焦点和实现基于资源方法（REST）的浪潮之间摇摆不定。事实上，在应用的世界里，SOA和REST服务于不同的目的，但两者都很有用，而且都服务于重要的目的。

　　明确什么时候使用REST

　　《SOA模式》一书的作者ArnonRotem-Gal-Oz认为在使事情简化方面，REST确实应得到它应有的表扬，但在只有在你正确使用它的情况下。“REST使服务大众化。它使能够创建使用简单的工具和接口，使事情进展顺利，且变得更敏捷。REST行动的一个好处理是它减少了障碍。你可能会陷入困境，就像使用其它任何一种技术一样的陷入困境中。但是使简单的事情简单化是一个大的胜利。”他说即使只是用HTTP了可以帮助你获得灵活性。

　　Brasier说，有一资源方法，你减少了很多不必要的开支。同时，它允许你有少量的误差，并具备一小点定制事务的能力。你需要大量的信息，包括资源结构，因为合同还没有定义。在不依靠SOA的情况下，你实际上不能把高复杂的查询放到一起。因此，在一个应用或两个连接紧密，互知对方的应用中，REST的效果很好。他们必须能够做出这样的假设：确定交付预期的结果。

　　不是SOA快

　　据Brasier所说，“SOA设计为高水平的架构，用于在整个企业范围内显示大粒度服务的各个部分，以及追踪这些服务之间的流量。”Brasier把当前REST的流行度看作是对于web服务和SOA不正确使用的一种映射。对于那些不需要等级管理和质量服务的行为，这并不是最好的答案。换句话说，你不必使用猎象的步枪去打鹌鹑，大材小用了。你要使工具与目标相符。

　　Arnon指出，SOA上升为最重要的位置，是因为对分布式系统创建的需求。它让你在引入灵活性的同时，对系统进行建模和组件化。这是原则问题，而不是严格遵守SOA的方式做事，从而带来好处。这一概念本身固有的灵活性使面向服务架构成为可能，即使它周围的技术发生了改变。