业界正在逐渐承认RESTful API优于面向服务架构。但是这对于架构师和开发人员而言到底意味着什么？Tom Nolle分享了他的想法。
在模块化应用世界里，最为持久的争论莫过于面向服务架构和表述性状态转移之争了。本文探讨这样的争论带来了什么及其背后的原因。
SOA已经被定性为连接组件和工作流的严格的且重量级的方案，REST则赢得了更多的赞誉。两者的特征都是简化，但是要学习RESTful API设计，架构师和开发人员必须理解SOA和REST之间的差异，学习REST和云以及微服务一起的演进，并且了解如何构建稳定且合规的RESTful工作流。
SOA广义上指基于连接的组件化服务的应用设计，基于这个定义，REST实际上是SOA的一种实现。实际API之争是在简单对象访问协议（SOAP）及实现其Web服务标准和REST之间。这两者有着本质的不同：SOAP从用于扩展网络连接之上的模块化编程的远地过程调用演进而来，而REST从互联网组件的“资源”角度而来。
有状态 vs. 无状态
使用SOAP，网络连接的组件是模块，也就是说他们可以被看成带有功能调用和参数的“过程”或者“类”。SOAP的目标是使得过程能够在远程工作，包括让开发人员找到过程，并且将其正确绑定到执行上。在REST的世界里，组件代表请求访问的资源——一个内部实现细节不透明的真正黑盒子。SOAP里不会假定远程组件是无状态的。本地过程以及REST则会假定调用是无状态的；在执行之间RESTful服务不会驻留任何东西。
云计算和微服务几乎已经使得RESTful API成为了既定业界标准，因此对于开发人员和架构师而言需要重点理解REST。
正是REST的无状态特征使其在云应用里作用非凡。当错误发生时，无状态组件可以随意重新部署，也可以在负载改变时随意伸缩。因为任意请求都可以发送到组件的任意实例上；不会有任何东西保存在另一个实例里，而需要下一次事务“记忆”住的。SOAP开发也可以这么实现，但并不是必须的。
基于这个原因，Web场景下更喜欢使用REST，不过在云服务里RESTful模型也很有用，因为通过API绑定到某个服务一般而言就是控制URL解析的方式。如果一个应用通过URL“知道”某个组件或者微服务，那么如果服务最初的实例出现故障，改变URL相关联的IP地址就会让请求路由到新的实例里。不需要其他额外的目录管理。如果URL指向某个负载均衡器，那么使用简单的算法就可以分发工作，因为没有哪个请求特别需要某个“记忆”了状态的特定实例来处理。
云和微服务
云计算和微服务几乎已经使得RESTful API成为了既定业界标准，因此对于开发人员和架构师而言需要重点理解REST。这意味着在应用里需要解决状态控制的一致性，管理安全性，从而解耦合组件并且创建高效的服务目录。
REST里有两种管理状态的方式——在RESTful调用里将状态传递给服务，或者由服务的任意实例都可以访问的后台数据库来维护状态。如果想要RESTful应用像基于SOAP的应用一样合规，那么就需要采取一致的方案。除非访问后台状态数据库的方案不现实，否则都应该考虑优先选择后台状态管理。客户端状态控制在客户端实例故障时会导致问题。
保证安全性
REST的安全问题很可怕，但是大多数情况下，这些安全问题的假设都是应用组件放置在开放的互联网或者VPN里。简单确定组件部署处的私有的RFC1918地址空间，可以大幅提高REST安全性。当组件间大规模集成对于应用而言必不可少时，这样的方案就不适用了，那么就有必要使用安全连接，比如https。身份令牌也可以作为RESTful API数据包的一部分。
有很多REST目录服务，ProgrammableWeb可能是其中最知名的服务，但是它们都关注于公开暴露的API。Internet社区内部关于私有RESTful API是否自相矛盾这个问题上存在争议，但是从实用的角度，大多数公司都需要使用私有API目录，从而让开发人员可以访问其RESTful API。否则，肯定会影响到企业数据和合规需求。
如果你在考察RESTful API目录工具，首先需要关注那些为微服务而设计的工具，因为这是云API领域的整体趋势。核心需求是支持三层API——私有内部或者甚至部门的API，“合作伙伴”或者社区API以及公开API。不过要记住，如果可以在网络地址空间里访问Web服务或者微服务，它就有可能被hack。即使API目录有安全保障，也同时需要考虑恰当的地址控制或者工作流加密。
REST和微服务使得组件整合更为容易，并且提供了云和虚拟化应用大规模扩展和弹性的可能性。通过解耦合SOAP引入的组件绑定规则来实现，那么应用规划师和开发人员可以通过其他方式实现安全和合规支持。REST和微服务在业界快速得到大量支持，因此需要在你的应用里准备好使用它们。
本文转自d1net（转载）