以RESTful方式许可和会话

Question

在我阅读这篇文章之后，这个问题在我脑海中浮现： “Common REST Mistakes: Sessions are irrelevant”

如果在RESTful应用程序中确实不鼓励会话。您将如何处理此类申请中的许可证。我特指的是并发许可证模型，而不是命名许可证。即客户购买X许可证，这意味着应用程序可以允许最多X个用户同时登录。这意味着应用程序必须保持当前登录用户的状态。

我知道我可以创建一个名为licenses的资源，它将设置一个cookie或生成一个唯一的ID，然后客户端必须在每次请求时发送它。但它与创建会话相同，对吧？

如果我采用无状态方法并要求客户端为每个请求创建一个身份验证令牌，应用程序将如何知道何时为该客户端使用和释放许可证？

还有其他选择吗？特别是一个更RESTful的替代方案？

Answer 1

假设我正确地解释了您的问题，让我尝试为您连接点。 您发布的链接具有有效答案，每个请求都应使用HTTP身份验证。如果您需要许可证的概念来维护用户的某种状态，您很可能会将其链接到用户。您有一个（已验证的）用户名。您只需为每个请求调用该控制器并保存其状态。你有你的会议。

任何关键信息都不应该信任Cookie输入，但对于安全令牌等额外验证非常有用。我认为在您的现场链接中添加一个随机安全令牌字段将是一种宁静的方法。当然，它应该以“会话”到期。

Answer 2

您可能需要考虑将基础架构堆栈中的许可证处理问题推迟一个级别。有点像面向方面编程（AOP）方法。也许，您可以将其推入Web服务器层，而不是在应用程序层中处理它。

如果不了解基础架构的详细信息，很难给出具体建议。以* nix平台为例，许可证处理逻辑可以实现为Apache HTTP服务器的模块。

此方法可促进基础架构堆栈中的关注点分离。它允许每一层专注于它的意图。应用程序层根本不需要担心许可，允许它严格关注内容，这反过来保持URL的清洁和“RESTful”。

Answer 3

如果您的许可基于并发用户，则实施HTTP摘要非常简单，并且只允许您启用最大并发登录次数。摘要提供了传递过期数据的功能，因此您的会话可以超时。

身份验证状态由http身份验证而不是其他地方，因为它是透明的，无处不在。

Answer 4

执行许可证的更多REST方式可能是限制处理请求的速率，而不是并发会话的数量。跟踪过去一小时内的请求数量，如果超过客户已支付的数量，请提供503 Service Unavailable响应，以及一些建议用户稍后再试的文字。