Question

我已经听说过RESTful service should be stateless. All state info should be stored in client. And each request should contain all the necessary state info。

但为什么呢？这样做的好处是什么？ Only when I know its benefit/motivation can I use it properly.

如果我的客户有大量的州，该怎么办？假设有一个在线文档编辑应用程序。客户端在调用服务器的RESTful API时是否必须发送他/她正在编辑的全文？或者这种情况是否不适合RESTful方法？

Answer 1

当谈到REST（或者很好的RESTful，因为没有多少人100％遵守我将引用的论文）服务我总是认为从源头开始是最好的，这意味着Fielding dissertation提到在5.1.3 Stateless：

此约束会引发可见性，可靠性和可伸缩性。能见度因为监控系统不必超越单个请求而得到改进 datum以确定请求的完整性。由于可靠性提高了它简化了从部分失败中恢复的任务[133]。可扩展性得到改善，因为不必在请求之间存储状态允许服务器组件快速释放资源，并进一步简化实现，因为服务器不必管理跨请求的资源使用情况。

它甚至进一步讨论了它的权衡：

与大多数架构选择一样，无状态约束反映了设计权衡。该缺点是它可能通过增加重复数据来降低网络性能（每个交互开销）在一系列请求中发送，因为该数据不能留在共享上下文中的服务器。此外，将应用程序状态放在客户端从应用程序开始，减少了服务器对一致应用程序行为的控制变得依赖于跨多个客户端的语义的正确实现版本

但菲尔丁即使在那里也没有停止，他谈到缓存以克服一些问题。

我强烈建议您浏览PDF，因为（据我记得）这是介绍REST的原始论文。

您提供的用例很难，而且很多人说这取决于您的具体情况。 RESTful服务被称为restFUL，而不是REST，因为人们发现原始论文过于局限，并决定放松一些规则（例如原始论文没有说什么关于批处理操作）。

Answer 2

主要优点是可扩展性 - 通过不需要为每个请求获取额外的上下文，您可以最小化服务器完成的工作量，这可能需要同时为许多请求提供服务。

此外，它有助于为您的API消费者提供更高的清晰度。通过让用户发送与正在进行的操作相关的所有内容，他们可以更清楚地看到实际上正在做什么，并且他们获得的错误消息通常可以更直接地作为结果;错误可以说出什么是错误的，为什么，而不是试图传达消费者在服务器上看不到的东西。

Answer 3

来自菲尔丁论文的同一章：

与大多数架构选择一样，无状态约束反映了一个设计权衡。 缺点是它可能会减少网络通过增加重复数据来提高性能（每次互动开销）在一系列请求中发送，因为不能保留该数据在共享上下文中的服务器上。

优点解释如下：

这种约束导致了可见性，可靠性和性能的特性   可扩展性。

可见性因为监控系统而得到改善   不必超越单个请求数据来确定   请求的完整性。

可靠性因为它而得到改善   减轻从部分失败中恢复的任务[133]。

可伸缩性得到改进，因为不必在请求允许之间存储状态   服务器组件可以快速释放资源，并进一步简化   实现，因为服务器不必管理资源   跨请求使用。

关于您的具体情况，是和否。这就是网络的运作方式。当我们在线编辑内容时，我们会将整个请求发送到服务器。虽然我们如何实现部分更新是一种设计选择。

可以通过向子资源发送PUT / POST请求来设计软件以实现此目标。例如：

PUT /book/chapter1 HTTP/1.1

PUT /book/chapter2 HTTP/1.1

PUT /book/chapter3 HTTP/1.1

而不是更新整个资源：

PUT /book HTTP/1.1
Content-Type: text/xyz
Content-Length: ...

为什么RESTful servics应该是无状态的？有什么好处？

3 个答案: