考虑一下情况。
我正在编写一个统计分析应用程序。该应用有多个层次。
由于统计分析需要大量处理能力的原因，您永远不会梦想将此类处理委托给前端。
统计分析包括程序或一系列程序 工作流程步骤。
某些步骤可能需要如此多的处理能力，您不会想要 重复一遍。
如果您的工作流程为20步，则无法执行步骤20 没有先执行步骤19，不能没有执行 首先执行步骤18，依此类推。
有观察点，例如， 统计员必须先检查步骤3,7,9,14,19的结果 告诉客户端继续下一步。
这些步骤中的每一步都是对REST服务的所谓请求 告诉后端超级计算机逐步建立 记忆中的统计模型。
有许多工作流程。某些工作流程可能偶然共享步骤 结果。例如，流[干]：步骤[7]可以共享流[湿]：步骤[10]。应有 对于涉及的处理量，我们绝对有预防 重复可能偶然发生的步骤 由另一个流程完成。
因此，您可以看到正在设计的所谓REST服务中， 每个请求都不可能独立于以前的任何请求。
因此，以下陈述的真实性如何？
所有REST交互都是无状态的。也就是说，每个请求都包含 连接器理解所需的所有信息 请求，独立于之前可能有的任何请求。
显然，我描述的应用程序要求请求依赖于先前的请求。关于这个应用，我可以看到三种可能性。
我的应用程序是否被视为RESTful？
新问题：ISO 9000
最后，如果我的应用程序未被完全视为RESTFul，是否需要省略所有对“REST”的引用才能通过ISO 9000认证？
新编辑：
REST的在片
好的，我的同事和我已经讨论过这个问题，并决定在零碎的阶段将这样的架构/模式称为REST-in-piece = REST。
答案 0 :(得分：8)
您的任务是确定资源是什么以及它们之间的“状态转移”。工作流中的每个步骤都是不同的状态转移，由不同的URI标记。每次更新/更改资源都有一个POST / PATCH或一个幂等的PUT或DELETE操作。
如果您想更好地了解RESTful的含义以及每种设计选择背后的原因，我建议您花一小时阅读Chapter 5 of Roy Fielding's Dissertation。
在做出设计选择时，只需考虑RESTful设计的原则是什么。设置你的设计，以便查询是安全的（不要改变状态），并且它们是以可收藏，可缓存，可分发等方式完成的。让工作流程中的每一步都跳转到具有不同URI的新状态，以便用户可以备份，分支出不同的方式等。整个想法是创建一个可扩展，灵活的设计。
答案 1 :(得分：2)
您正在通过REST API更新内存模型。这意味着您在请求之间维护服务器上的状态。
解决这个问题的REST-ful方法是通过简单地处理请求并返回用于在响应中构造下一个请求的所有信息来使客户端维持状态。然后，服务器根据请求中的信息重建内存模型，然后执行其操作。这样，如果你在一个例如在集群环境中，任何可用的服务器都能够处理请求。
这是否是最有效的处理方式取决于您的应用程序。有许多企业应用程序使用服务器端会话和精心设计的负载平衡，以确保客户端始终使用群集中的相同节点。因此，拥有服务器端状态是一个完全有效的设计选择，并且有很多方法可以有效地实现这一点。但是，服务器端状态通常使扩展变得复杂，而最纯粹意义上的REST就是避免服务器端状态并避免复杂性。
解决方法/妥协是在某种数据库或商店中保持状态。这样，您的节点可以在处理请求之前从磁盘获取状态。
这完全取决于您需要什么以及您可接受的内容。正如之前的评论者提到的那样，不要太过于沉溺于整个有状态的事情。显然，有人必须保持状态，而问题仅仅在于为您提供该状态以及如何访问它的最佳位置。基本上有几个权衡基本上与各种假设类型的场景有关。例如，如果服务器崩溃，您是否希望客户端重新运行整个请求集以重建计算，或者您是否只想重新发送最后一个请求？我可以想象你在这里并不需要高可用性，也不介意为你的客户偶尔出现问题的低风险。在这种情况下，将服务器端的状态置于内存中是一种可接受的解决方案。
假设您的服务器在某些哈希映射中保持计算状态，那么传递状态的REST-ful方式可以简单地在响应中发回模型的密钥。这是一个完美的REST-ful API，您可以更改实现以持久保存状态或执行其他操作而无需在需要时更改API。这是REST-ful的主要观点：将实现细节与API分离。您的客户不需要知道您放置州的位置或存储方式。它所需要的只是该状态的资源表示，可以被操纵。
当然密钥应该表示为URI。我建议你阅读Jim Webber的“实践中的REST”。这是设计REST-ful API的一个很好的介绍。