20

在阅读了关于 REST 的介绍性文章(菲尔丁的论文和其他)之后,我对无状态的看法是服务器端不应该有会话对象。然而,我看到Flask(可能还有其他我不知道的不同技术的 REST 框架)在这个例子中为我们提供了一个会话对象来在服务器上存储信息:

@app.route('/login', methods=['GET', 'POST'])
def login():
  if request.method == 'POST':
    session['username'] = request.form['username']
    return redirect(url_for('index'))
...

当然,我误解了 REST 的无状态性。那么,它到底是什么?

4

3 回答 3

5

在 REST 中引入无状态约束的目的包括提高可见性、可靠性和可扩展性。这意味着代理和其他中介能够更好地参与涉及自描述无状态消息的通信模式,服务器死亡和故障转移不会导致会话状态同步问题,并且很容易添加新服务器以再次处理客户端负载,而无需需要同步会话状态。

REST 通过多种机制实现无状态:

  1. 通过设计方法和通信模式,它们不需要在请求后将状态保留在服务器端。
  2. 通过设计公开功能的服务,以直接采样和转换服务器端状态,而没有剩余的应用程序状态
  3. 每当需要会话状态或应用程序状态时,通过“延迟”或在每个请求结束时将状态作为消息传递回客户端

最后一点暴露了无状态的缺点:需要某种会话状态的应用程序在单个请求的持续时间之后仍然存在,需要将该状态作为响应消息的一部分发送回客户端。下次客户端想要发出请求时,状态会再次传输到服务,然后返回客户端。

您可以从这里获取更多信息http://soundadvice.id.au/blog/2009/06/

于 2012-11-03T07:10:28.583 回答
1

不,你很好理解。RESTful 服务中不应有任何“会话”。始终检查您是否可以通过邮件发送任何 URI,将其保存在书签中,并在链接中引用它。这确实是 REST 对 Web 如此重要的原因:没有 RESTful 资源 = 没有更多链接。仅应在访问资源表示时进行身份验证。

您可以拥有一个可以通过 REST 方法修改的用户对象(例如购物车),而不是会话。这与会话不同,因为例如,可能存在您可以授权其他人查看您的购物车的服务。

于 2012-11-03T07:19:02.693 回答
1

在 REST 架构中,会话状态完全保存在客户端上。这意味着数据不能在共享上下文中留在服务器上,我们仍然必须在一系列请求中发送重复数据(每次交互开销)。当我们在客户端保持应用程序状态时,这减少了服务器对一致应用程序行为的控制,因为应用程序变得依赖于跨多个客户端版本的语义的正确实现。然而,这种约束导致了可见性、可靠性和可扩展性的属性。

  • 可见性得到提高,因为监控系统不必超越单个请求数据来确定请求的全部性质。
  • 可靠性得到了提高,因为它简化了从部分故障中恢复的任务。
  • 可扩展性得到了改进,因为不必在请求之间存储状态允许服务器组件快速释放资源,并进一步简化了实现,因为服务器不必管理请求之间的资源使用。

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

于 2017-04-09T06:03:40.427 回答