会话真的违反了 REST 性吗? [英] Do sessions really violate RESTfulness?

问题描述

在 RESTful API 中使用会话真的违反了 RESTfulness 吗?我已经看到很多意见都朝着任何一个方向发展，但我不相信会议是RESTless.从我的角度来看:

Is using sessions in a RESTful API really violating RESTfulness? I have seen many opinions going either direction, but I'm not convinced that sessions are RESTless. From my point of view:

• RESTful 不禁止身份验证(否则在 RESTful 服务中几乎没有用处)
• 身份验证是通过在请求中发送身份验证令牌来完成的，通常是标头
• 此身份验证令牌需要以某种方式获取并且可能会被撤销，在这种情况下需要更新
• 身份验证令牌需要由服务器验证(否则就不是身份验证)

那么会话如何违反这一点?

So how do sessions violate this?

• 客户端，使用cookies实现会话
• cookies 只是一个额外的 HTTP 标头
• 可以随时获取和撤销会话 cookie
• 如果需要，会话 cookie 可以有无限的生命周期
• 会话 ID(身份验证令牌)在服务器端进行验证

因此，对于客户端，会话 cookie 与任何其他基于 HTTP 标头的身份验证机制完全相同，除了它使用 Cookie 标头而不是 Authorization> 或其他一些专有标头.如果没有会话附加到 cookie 值服务器端，为什么会有所不同?只要服务器行为 RESTful，服务器端实现就不需要关心客户端.因此，cookie 本身不应该使 API RESTless，会话只是客户端的 cookie.

As such, to the client, a session cookie is exactly the same as any other HTTP header based authentication mechanism, except that it uses the Cookie header instead of the Authorization or some other proprietary header. If there was no session attached to the cookie value server-side, why would that make a difference? The server side implementation does not need to concern the client as long as the server behaves RESTful. As such, cookies by themselves should not make an API RESTless, and sessions are simply cookies to the client.

我的假设是错误的吗?是什么让会话 cookie RESTless?

Are my assumptions wrong? What makes session cookies RESTless?

推荐答案

首先，让我们定义一些术语:

First, let's define some terms:

• RESTful:

• RESTful:

可以表征符合 REST 约束的应用程序在本节中描述为RESTful". [15]如果一项服务违反任何在所需的约束中，它不能被视为 RESTful.

One can characterise applications conforming to the REST constraints described in this section as "RESTful".[15] If a service violates any of the required constraints, it cannot be considered RESTful.

根据维基百科.

无状态约束:

接下来我们为客户端-服务器交互添加一个约束:通信本质上必须是无状态的，如第 3.4.3 节的客户端-无状态-服务器 (CSS) 样式(图 5-3)，这样从客户端到服务器的每个请求都必须包含所有理解请求所必需的信息，并且不能采取任何存储在服务器上的上下文的优势.会话状态是因此完全保留在客户端.

We next add a constraint to the client-server interaction: communication must be stateless in nature, as in the client-stateless-server (CSS) style of Section 3.4.3 (Figure 5-3), such that each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.

根据外勤论文.

因此服务器端会话违反了 REST 的无状态约束，因此也违反了 REST 性.

So server side sessions violate the stateless constraint of REST, and so RESTfulness either.

因此，对于客户端，会话 cookie 与任何其他基于 HTTP 标头的身份验证机制，除了它使用Cookie 标头而不是 Authorization 或其他一些专有标头.

As such, to the client, a session cookie is exactly the same as any other HTTP header based authentication mechanism, except that it uses the Cookie header instead of the Authorization or some other proprietary header.

通过会话 cookie，您将客户端状态存储在服务器上，因此您的请求具有上下文.让我们尝试向您的系统添加负载均衡器和另一个服务实例.在这种情况下，您必须在服务实例之间共享会话.这样的系统很难维护和扩展，所以它的伸缩性很差......

By session cookies you store the client state on the server and so your request has a context. Let's try to add a load balancer and another service instance to your system. In this case you have to share the sessions between the service instances. It is hard to maintain and extend such a system, so it scales badly...

在我看来，cookies 没有任何问题.cookie 技术是一种客户端存储机制，其中存储的数据通过每个请求自动附加到 cookie 标头.我不知道对那种技术有问题的 REST 约束.所以技术本身没有问题，问题在于它的使用.Fielding 写了一个小节来说明他为什么这么认为HTTP cookie 很糟糕.

In my opinion there is nothing wrong with cookies. The cookie technology is a client side storing mechanism in where the stored data is attached automatically to cookie headers by every request. I don't know of a REST constraint which has problem with that kind of technology. So there is no problem with the technology itself, the problem is with its usage. Fielding wrote a sub-section about why he thinks HTTP cookies are bad.

从我的角度来看:

• RESTful 不禁止身份验证(否则在 RESTful 服务中几乎没有用处)
• 身份验证是通过在请求中发送身份验证令牌来完成的，通常是标头
• 此身份验证令牌需要以某种方式获取并且可能会被撤销，在这种情况下需要更新
• 身份验证令牌需要由服务器验证(否则就不是身份验证)

你的观点很中肯.唯一的问题是在服务器上创建身份验证令牌的概念.你不需要那部分.您需要的是在客户端存储用户名和密码，并随每个请求发送.除了 HTTP 基本身份验证和加密连接之外，您不需要更多:

Your point of view was pretty solid. The only problem was with the concept of creating authentication token on the server. You don't need that part. What you need is storing username and password on the client and send it with every request. You don't need more to do this than HTTP basic auth and an encrypted connection:

• 图 1. - 受信任客户端的无状态身份验证

您可能需要在服务器端使用内存中的身份验证缓存来加快速度，因为您必须对每个请求进行身份验证.

You probably need an in-memory auth cache on server side to make things faster, since you have to authenticate every request.

现在这对于您编写的受信任客户端来说效果很好，但是对于 3rd 方客户端呢?他们不能拥有用户名和密码以及用户的所有权限.因此，您必须单独存储特定用户可以拥有的第 3 方客户端的权限.所以客户端开发者可以注册他们的 3rd 方客户端，并获得一个唯一的 API 密钥，用户可以允许 3rd 方客户端访问他们的部分权限.像阅读姓名和电子邮件地址，或列出他们的朋友等...在允许 3rd 方客户端后，服务器将生成一个访问令牌.3rd 方客户端可以使用这些访问令牌来访问用户授予的权限，如下所示:

Now this works pretty well by trusted clients written by you, but what about 3rd party clients? They cannot have the username and password and all the permissions of the users. So you have to store separately what permissions a 3rd party client can have by a specific user. So the client developers can register they 3rd party clients, and get an unique API key and the users can allow 3rd party clients to access some part of their permissions. Like reading the name and email address, or listing their friends, etc... After allowing a 3rd party client the server will generate an access token. These access token can be used by the 3rd party client to access the permissions granted by the user, like so:

• 图 2. - 第三方客户端的无状态身份验证

因此第 3 方客户端可以从受信任的客户端(或直接从用户)获取访问令牌.之后，它可以使用 API 密钥和访问令牌发送有效请求.这是最基本的 3rd 方身份验证机制.您可以在每个 3rd 方身份验证系统的文档中阅读有关实现细节的更多信息，例如身份验证.当然，这可以更复杂和更安全，例如您可以在服务器端签署每个请求的详细信息，并将签名与请求一起发送，等等......实际的解决方案取决于您的应用程序的需要.

So the 3rd party client can get the access token from a trusted client (or directly from the user). After that it can send a valid request with the API key and access token. This is the most basic 3rd party auth mechanism. You can read more about the implementation details in the documentation of every 3rd party auth system, e.g. OAuth. Of course this can be more complex and more secure, for example you can sign the details of every single request on server side and send the signature along with the request, and so on... The actual solution depends on your application's need.

这篇关于会话真的违反了 REST 性吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！