组件化应用程序需要机制来将组件传递到下一个工作地。从一开始，人们对连接流程及其实施就有不同的观点。可以证明，SOA阵营是由远程流程调用（RPC）和简单对象访问协议（SOAP）的软件接口发展而形成的。这种方法会形成一种安全和高结构的界面。

从互联网的角度来看，这种界面开始被视为HTML的远程资源引用。该流程被正式应用于具象状态传输（REST），如今有迹象表明第三种模式可能会出现。要判断新模式的诞生是否言过其实，重要的是考虑哪些因素可能会推动这样的发展，需要解决哪些问题以及革新和演变是否是最优的方法。

SOA和REST架构所面临的压力

第一阶段，为了适应两个关键的应用趋势，SOA和REST已经存在压力。这两种趋势分别是支持活动点上的工作人员以及使用弹性虚拟资源来构建组件。对于架构师来说，重要的是要弄清楚在超越媒体以及厂商推广的范围内这些因素究竟带来多少压力。

移动设备往往会为工作者提供更有针对性的信息，因为他们在研发过程中会选择性的使用这些信息。既然向工作人员展示哪种信息是属于Web前端或者独立GUI组件的功能，那么进行更改以支持移动设备可能不需要改变组件化模型。如果是这样的话，需要略微地考虑选择一种新的应用程序界面。

弹性资源提出了一个更直接的挑战，尤其是对云计算而言。大部分工作人员是通过云应用程序访问互联网和VPN网络的，这对RESTful接口产生了很大的促进作用。然而，为了能在数据中心运行而设计的应用程序通常是基于SOA技术的，而不是通过回应负载量的改变增加或者减少组件而实现资源弹性化。正是这种挑战为新接口带来了更多的需求，然而大部分事物都是动态的如REST，但却往往都是安全的、可控的，如SOA、SOAP和Web服务（WS）。

在资源弹性区，REST限制往往被架构师认为是缺乏对扩大或缩小的明确支持。架构师所认为需要解决的问题是如何平衡共享工作流的组件之间的负载以及控制复制的组件与原始组件的状态。

REST假定该状态是由客户端控制，但大多数应用程序又都有状态更新提示。即使一些网络活动可以通过平衡负载量而在不同的组件上更改客户或者组件接口，但是这种方法会迫害应用程序。后端状态控制似乎是一个合理的方案，然而却未能提供一种标准的方法或者判断这种方法是否可行。

即使没有动态资源及其影响，组件化应用程序以及其他组件也会对REST造成压力。架构师们最关心的问题是对功能和性能的绑定组件缺乏明确的支持

与大多数SOA绑定功能有所不同，该绑定可以访问WSDL，而对于REST验证功能却没有明确的支持，接口处也没有参数支持。有人建议建立一种标准的方法来验证客户和组件在连接过程中的兼容性，但是却没有找到一种较满意的方法。如果客户与组件的连接关系发生改变，那么绑定控制中出现的问题是非常复杂的，因为，要解决问题就需要扩大或者缩小规模，也需要平衡负载量。

我们可以将应对REST API挑战的解决方案视为加强REST功能的一系列方案，使其更接近于SOAP，改变SOA使其更RESTful，或者创建一个集二者于一身的新标准。考虑到应用程序已经应用到SOA或者REST API中，这种全新的方法似乎不太可能成功。以渐进的方式来解决组件规模扩大和资源虚拟化中出现的问题可能是最好的方法了。

解决REST架构中出现的困境

大多数人相信，当客户第一次从目录上获得指令访问RESTful API时，增强REST的最佳方法是绑定目录。该指令提供了应用程序的链接，并提供验证服务（负载平衡，状态控制）和数据交换的特定格式。由于这与SOA中使用WSDL的情况很像，因此，我们称之为REST的WSDL扩展也是合乎情理的。REST API是否需要一个回复指令或者是否可以认为是正常的REST行为，这将是一个选择的问题。

我们已经完成了从SOA API时代到RESTful模式的跨越。通常，这意味着已经实现了应用程序的连接以及通过消除组件状态控制和SOAP来实现RESTful。这种SOA的REST扩展似乎也需要借鉴API的演进要点。

当前，SOA和REST在完成各自的任务过程中都非常安全。现在的问题是新的应用程序是否将要创建一种动态关系，在需要另外一种方法的时候能起到加强REST和SOA的作用。如果这种方法更多的是源于云计算，那么REST的WSDL扩展版有可能成为首选的接口。如果当前的应用程序推动了该发展进程，那么，也将会推动SOA的发展，并且REST将会继续专注于Web前端流程。任何一种情况下，REST的继承者都很可能会整合SOA和REST两种原则。