要想控制住云中状态，架构师应该先实现一种REST友好界面，而不是考虑设计出一种REST架构模型。

RESTful界面即用户所说的RESTful服务，架构师们希望用户通过RESTful界面可以维护整个流程状态，因为在多级事务中很需要这种状态记录行为。但是，这种做法会给应用程序或者用户端增加一种负担，尤其是当需要从浏览器进行访问时。

在状态控制阶段，架构师需要探索一种REST友好（REST-friendly）界面，而不是REST架构模型。转移和维持RESTful模型费用应当着眼于，增加状态控制对工作流及云效果的影响上。

状态这一概念对大多数在线应用程序都十分重要，因为，要想完成一项活动需要许多信息，而这些信息又需要通过几次叠加完成。状态信息必须设置在流程连续的位置上，这样用户就可以精准地获取这些信息。一次更新通常包含以下内容：

第一阶段要更新需求数据
第二阶段要更新用户或者客户的显示及更新数据
第三阶段通过应用程序或者 DBMS进行更新
显示更新结果

进行状态控制讨论最佳的切入点是，辨识REST友好与REST架构的差异。严格地来说，RESTful状态控制就是用户或者客户所保持的应用状态。REST友好意味着潜在资源可以管理客户行为状态。RESTful状态控制和REST友好不仅在技术上存在差异，而且在目前恢复和审计抉择上也存在差异。当客户端维持应用程序流程状态时，要想通过检查关系资源决定多阶段事务状态就非常困难。尤其对于手机客户端来说，连接损耗可以使事务和数据库的完整性工作变得非常复杂。用户反映，采用事务完整性的恢复及审计最大的原因是要避免使用客户状态维持模型。

状态控制的备选模型

后端状态控制、在状态流中使用Web前端技术以及逻辑嵌入式状态管理，这三种模型平分状态控制领域。这三种模型都可以实现RESTful界面和可靠的控件状态。

后端状态控制意味着，从一开始，每个客户活动就会产生一组内容记录，并以对话的形式展现出来。这段记录包含了对话及对话状态所产生的所有信息。当需要新的REST调用时，与调用设备或者应用程序相连接的内容记录就会重新恢复使用，并根据该内容重新处理输入信息。如果多级对话处在一个不完整的状态下，那么内容记录就可以被用于还原信息以及将数据库恢复到基本状态下。

后端控件通常需要重新设计应用程序。而与此相反的一面就是Web前端。在这里，用户设备可以实现一种带有Web媒介服务器的RESTful界面，而该服务器是可以管理应用程序关系的。服务器端应用程序可以维持客户行为状态。如果处理适当，我们可以在Web服务器倒退到不完整事务流程时还可以获取到足够多的信息。在需要采用现有SOA或者REST状态组件时，也可以考虑使用这种方法。

第三种方式是通过分析客户所提供的信息将状态控件隐式地嵌入到应用程序逻辑中。当获取到所需信息时，根据缺失信息以及发布的事务，此次完整性的检查结果就会分发给各屏幕。该方法期望 RESTful API可以提供所有数据，同时，可以持续不断地反馈不完整信息指示，直到不完整信息补充完全。

有一些公司倾向于这种模型，因为，它可以让客户界面很好的适应状态数据，即一种较为合理的模式，而不是设置有误的状态变量。同时，也可将其应用到Web前端中，因此，可作为第二种备选方案。

逻辑方法压倒一切

基于逻辑的方法同时也是现代数据驱动流程、应用程序推动工作或活动的衍生物。许多事件驱动系统都是采用一种程序模板、并通过基于一种表格或者策略集合的某一状态/事件或者数据/流程模型来掌控事件。对于应用程序来说，这种做法非常有价值，因为，该应用程序中的活动或者交易所包含的信息可以源自许多资源，如传统设备、M2M传感器和其他应用程序。所有活动均被缩减为一系列事件，这样就可以轻松地表示为RESTful API。

最后，状态控件逻辑流程更倾向于将组件降低到数据元素的水平。这有助于处理离散事件中任何一个元素。低级组件化有助于推进敏捷开发以及组件重用技术，但是这种做法却增加了工作流程开销的风险。

考虑到基于逻辑的状态控件对于M2M以及物联网来说是一种固有的，或者最起码也是一种相关的属性，因此，明智的做法是采用几种管理工作流延迟的方法以及考虑其对质量体验的诸多影响。否则，应用程序的开发之路将会被终止。

考虑将RESTful状态控件作为优选策略存在一定风险。对于这些使用当前应用程序的企业来说，可以肯定的是，简易的前端状态控制流程将会需要最少的时间和最低的费用。当使用组件负载分担技术时，更多的企业选择使用后端状态控制，因为，如果是存储在分量图像中，那么后端内容记录将会引导REST API调用的正确处理流程。

尽管其他方法也很受欢迎，但是有许多力量会推动状态控件走向最终模型，其中最重要的一个因素就是应用程序对用户或者工作人员工作场所、位置以及其他内容分析的发展变革。所有这些方法都会在短时间内发生改变，而对于支持简单状态驱动流程的传统客户端或者服务器对话框都是异步的。因为组件共享管理存在一定的困难，同时，状态控制机制中所使用的敏捷或者动态开发也有所不同，因此，逻辑或者数据驱动模型将会大受欢迎。