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

我听够了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方法？

谈论REST(或者很好的RESTful,因为没有多少人100%遵守我将在这里引用的论文)服务我总是认为最好从源头开始,这意味着Fielding的论文提到5.1.3 Stateless:

此约束会导致可见性,可靠性和可伸缩性.可见性得到改善,因为监控系统不必超出单个请求数据,以确定请求的完整性质.可靠性得到改善,因为它简化了从部分故障中恢复的任务[133].可扩展性得到改善,因为不必在请求之间存储状态允许服务器组件快速释放资源,并进一步简化实现,因为服务器不必管理跨请求的资源使用.

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

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

但菲尔丁并没有就此停止,他谈到缓存以克服一些问题.

我强烈建议你仔细阅读PDF,因为(据我所记得)这是引入REST的原始论文.

您提供的用例很难,而且很多人说这取决于您的具体情况.RESTful服务被呼叫,restFUL而不是REST因为人们发现原始论文过于局限并且决定放松一些规则(例如原始论文没有说明批处理操作).