在组件化应用程序世界中，争论最久的似乎是在面向服务的体系结构和表示状态转移之间的争论。
SOA已经成为组件连接和工作流的僵化和重量级方法，而REST越来越受欢迎。这两种特性都很简单，但是要开始使用RESTful API设计，架构师和开发人员必须了解SOA和REST之间的区别，跟踪REST在云和微服务中的发展，并知道如何构建可靠且兼容的RESTful工作流。
SOA是基于链接和组件化服务的应用程序设计的广义术语，从广义上讲，REST实际上是SOA的一个实现。API是简单对象访问协议（SOAP）和用于实现它和REST的Web服务标准之一。两者之间的差异源自它们的根源：SOAP是从用于通过网络连接扩展模块化编程的远程过程调用技术演变而来的，而REST是从Internet的组件“资源”视图演变而来的。
有状态与无状态
在SOAP中，网络组件是模块，这意味着它们可以被看作是带有函数调用和参数的“过程”或“类” 。SOAP的目标是使过程以远程形式工作，包括让开发人员找到过程正确地绑定到过程并执行。使用REST，组件代表您请求访问的资源，其实现细节是不透明的。SOAP不能假定远程组件是无状态的。对于本地过程也是如此，其中使用REST的前提是所有调用都是无状态的；RESTful服务在执行之间不能保留任何内容。
正是这种无状态的属性使REST在云应用程序中变得有用。如果出现故障，可以*地重新部署无状态组件，并且可以进行缩放以适应负载变化。这是因为任何请求都可以定向到组件的任何实例。在另一个实例中保存的任何内容都不能以某种方式被下一个事务“记住”。
仅出于这个原因，REST是Web使用的首选，但是RESTful模型在云服务中也很有用，因为通过API绑定到服务只是控制URL的解码方式。如果应用程序通过URL“知道”某个组件或微服务，那么如果原始组件实例失败，更改与该URL关联的IP地址将使请求重定向到实例。不需要其他目录管理。如果使URL指向负载均衡器，那么简单的算法就可以分发工作，因为任何请求都不能由“记住”状态的实例来处理。
云和微服务
云计算和微服务几乎会使RESTful API设计成为未来的规划，因此，对于开发人员和架构师而言，充分利用REST至关重要。这意味着在应用程序中一致地处理状态控制，在组件耦合较松的情况下管理安全性，并创建有效的服务目录。
有两种方法可以管理REST中的状态，在RESTful调用中将状态传递给服务，或者让服务的任何实例都可以访问后端数据库来维护状态。如果您希望RESTful应用程序像基于SOAP的应用程序那样兼容，那么采取一致的方法至关重要。除非访问后端状态数据库是不切实际的，否则请考虑将后端状态管理作为首选。如果客户端实例失败，客户端状态控制可能会导致问题。
保持安全
REST中的安全性问题可能是可怕的，但在大多数情况下，它们都与应用程序的组件在开放Internet或VPN上处理的假设有关。REST安全性中的一个主要步骤可以简单地通过建立一个私有RFC1918地址空间来实现，组件部署在这个地址空间中。如果由于组件间的广泛集成对应用程序至关重要而无法实现，那么使用https之类的安全连接就足够了。Token也可以成为RESTful API数据包的一部分。
REST和微服务可轻松实现组件集成，并在云和虚拟化应用程序中提供了更大的可伸缩性和恢复能力。尽管他们这样做的部分原因是放宽了SOAP组件绑定的严格规则，但应用程序规划和开发人员可以通过其他方式增强安全性和合规性支持。无论如何，REST和微服务似乎正在迅速获得支持，因此明智的做法是准备在自己的应用程序中使用它们。