java – 实践中的REST真的可以是无状态的吗?

前端之家收集整理的这篇文章主要介绍了java – 实践中的REST真的可以是无状态的吗?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
考虑一下情况.

我正在写一个统计分析应用程序.该应用程序有多个层.

>为多种设备类型,桌面,浏览器编写的前端UI
移动.
>提供所谓REST服务的中间层servlet
这些前端.
>后端执行统计的极端计算
处理.
>与另一个后端数据库进行通信

由于统计分析需要大量处理能力的原因,您永远不会梦想将此类处理委托给前端.

>统计分析包括程序或一系列程序
工作流程步骤.
>某些步骤可能需要如此多的处理能力,您不会想要
重复它们.
>如果您的工作流程为20步,则无法执行步骤20
没有先执行步骤19,不能没有执行
首先执行步骤18,依此类推.
>有观察点,例如,
统计员必须先检查步骤3,7,9,14,19的结果
告诉客户端继续下一步.
>这些步骤中的每一步都是对REST服务的所谓请求
告诉后端超级计算机逐步建立
记忆中的统计模型.
>有许多工作流程.某些工作流程可能偶然共享步骤
结果.例如,流[干]:步骤[7]可以共享流[湿]:步骤[10].应有
对于涉及的处理量,我们绝对有预防
重复可能偶然发生的步骤
由另一个流程完成.

因此,您可以看到在所谓的REST服务中,
每个请求都不可能独立于任何先前的请求.

因此,以下陈述的真实性如何?

All REST interactions are stateless. That is,each request contains
all of the information necessary for a connector to understand the
request,independent of any requests that may have preceded it.

显然,我描述的应用程序要求请求依赖于先前的请求.关于这个应用,我可以看到三种可能性.

>我的应用程序不符合REST,因为它无法满足无状态请求.它可能使用JAX-RS框架,但是使用JAX-RS和REST的所有陷阱并不能使它成为REST,仅仅因为它无法通过无状态标准.
>我的应用程序设计糟糕 – 即使工作流程需要5到15分钟,我也应该忽略试图避免重新计算统计模型的时间和财务成本.只要确保不依赖以前的请求.必要时重复昂贵的步骤.
>无国籍标准已过时.我对REST的理解已经过时/有缺陷,因为REST社区一直忽视这个标准.

我的应用程序被认为是RESTful吗?

新问题:ISO 9000

最后,如果我的应用程序不完全被认为是RESTFul,是否需要省略所有对“REST”的引用才能通过ISO 9000认证?

新编辑:

REST-在片

好的,我的同事和我已经讨论过这个问题,并决定在零碎的阶段中调用这样的架构/模式REST-in-piece = REST.

解决方法

ISTM,你对无国籍状态的阅读太多了. REST API支持传统的 CRUD operations. CouchDB的API是一系列无状态事务如何更新DB状态的一个很好的例子.

您的任务是确定资源是什么以及它们之间的“状态转移”.工作流中的每个步骤都是不同的状态转移,由不同的URI标记.每次更新/更改资源都有一个POST / PATCH或幂等PUT或DELETE操作.

如果你想更好地理解什么是RESTful的意义以及每个设计选择背后的原因,我建议花一个小时阅读Chapter 5 of Roy Fielding’s Dissertation.

在做出设计选择时,只需考虑RESTful设计的原则是什么.设置你的设计,以便查询是安全的(不要改变状态),并且它们是以可收藏,可缓存,可分发等方式完成的.让工作流程中的每一步都跳转到具有不同URI的新状态,以便用户可以备份,分支出不同的方式等.整个想法是创建一个可扩展,灵活的设计.

猜你在找的Java相关文章