为什么代币被认为是无状态的？
Why are tokens considered stateless?
所以我有点想理解为什么 "tokens" 对不同的新 Web 身份验证技术大肆宣传。
我知道这是为了改进您在使用 cookie 和会话时可以 "lose" 的控制。但是很多人都在谈论这样一个事实，即它通过允许客户端-服务器通信是无状态的来坚持 Restful "ideology"。
但是……是吗？我的意思是，无状态通信意味着服务器不必在客户端上存储任何信息以进行身份验证，并且请求之间是 100% 独立的。
在令牌的情况下：
服务器显然需要存储这些（就像在大多数应用程序中的客户端一样，如果你想在重启时保留令牌）所以，客户端和服务器都有一个状态。
客户端需要轮询“/get token”才能请求其他任何东西，并且此请求的结果关闭了任何进一步请求的结果。换句话说，如果我在设计一个状态图，我的图会包含多个状态。
所以对我来说，代币与我们所说的 "stateless" 通信（这是架构成为 Restful 的必要条件）相去甚远。
顺便说一句，我认为 HTTP 凭据更接近于实现无状态通信，因为基本上，即使服务器通过存储凭据仍然具有状态，auth+request 过程仅依赖于一个请求，(因为凭据是 HTTP "conversation").
的第一个请求的完整部分
另一个 HTTP 凭据比令牌更受欢迎的一点是 Restful API 中的 "Client/server roles"。这一点表明 RESTFul 通信拆分了客户端和服务器，这意味着客户端不必处理数据存储。但就令牌而言，它们肯定需要存储，至少是暂时的（如果（例如）您希望浏览器在重启后通过使用 cookie 或 localstorage 保留令牌甚至更多）。相比之下，HTTP cred 可以由用户在每次对话请求时填写，使客户端不存储数据，就像它应该在 Restful 表示中一样。
我还想指出，根据 Rest 架构，客户端持有的任何信息本身就足以让客户端决定他是否应该 delete/modify 它，这不是99% 的令牌系统不会让客户端存储令牌的超时日期（cookie 会这样做）的情况。
所以总而言之，很多人指责 HTTP 信用或会话违反了架构的 Restfulness。但是令牌系统根本没有解决问题，对吗？
如您的评论所述，我假设您指的是 jwt.io。
Server obviously needs to store those ( just as the client in most
cases of applications if you want to keep token over restart) so, both
client and server does have a states.
不要求服务器存储任何状态。即使 jwt.io 上的默认示例也证明了这一点：
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
使用 JSON Web 令牌，此信息被签名并存储在客户端上。不知道秘密就无法更改信息，因此在此设计中，如果使用 "strong enough" 密钥，则认为它是安全的。
这就是为什么它可以被认为是无状态的。正如您提到的，客户端确实需要存储令牌并因此携带状态。然而，服务器没有，这意味着服务器端的实现可以被认为是无状态的。
所以我有点想理解为什么 "tokens" 对不同的新 Web 身份验证技术大肆宣传。
我知道这是为了改进您在使用 cookie 和会话时可以 "lose" 的控制。但是很多人都在谈论这样一个事实，即它通过允许客户端-服务器通信是无状态的来坚持 Restful "ideology"。
但是……是吗？我的意思是，无状态通信意味着服务器不必在客户端上存储任何信息以进行身份验证，并且请求之间是 100% 独立的。
在令牌的情况下：
服务器显然需要存储这些（就像在大多数应用程序中的客户端一样，如果你想在重启时保留令牌）所以，客户端和服务器都有一个状态。
客户端需要轮询“/get token”才能请求其他任何东西，并且此请求的结果关闭了任何进一步请求的结果。换句话说，如果我在设计一个状态图，我的图会包含多个状态。
所以对我来说，代币与我们所说的 "stateless" 通信（这是架构成为 Restful 的必要条件）相去甚远。
顺便说一句，我认为 HTTP 凭据更接近于实现无状态通信，因为基本上，即使服务器通过存储凭据仍然具有状态，auth+request 过程仅依赖于一个请求，(因为凭据是 HTTP "conversation").
的第一个请求的完整部分另一个 HTTP 凭据比令牌更受欢迎的一点是 Restful API 中的 "Client/server roles"。这一点表明 RESTFul 通信拆分了客户端和服务器，这意味着客户端不必处理数据存储。但就令牌而言，它们肯定需要存储，至少是暂时的（如果（例如）您希望浏览器在重启后通过使用 cookie 或 localstorage 保留令牌甚至更多）。相比之下，HTTP cred 可以由用户在每次对话请求时填写，使客户端不存储数据，就像它应该在 Restful 表示中一样。
我还想指出，根据 Rest 架构，客户端持有的任何信息本身就足以让客户端决定他是否应该 delete/modify 它，这不是99% 的令牌系统不会让客户端存储令牌的超时日期（cookie 会这样做）的情况。
所以总而言之，很多人指责 HTTP 信用或会话违反了架构的 Restfulness。但是令牌系统根本没有解决问题，对吗？
如您的评论所述，我假设您指的是 jwt.io。
Server obviously needs to store those ( just as the client in most cases of applications if you want to keep token over restart) so, both client and server does have a states.
不要求服务器存储任何状态。即使 jwt.io 上的默认示例也证明了这一点：
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
使用 JSON Web 令牌，此信息被签名并存储在客户端上。不知道秘密就无法更改信息，因此在此设计中，如果使用 "strong enough" 密钥，则认为它是安全的。
这就是为什么它可以被认为是无状态的。正如您提到的，客户端确实需要存储令牌并因此携带状态。然而，服务器没有，这意味着服务器端的实现可以被认为是无状态的。