REST 服务中的会话
我正在开发小型 REST 服务，该服务应该支持客户端会话持久性。如您所知，由于 REST，我们无法在服务器上存储任何客户端数据，数据必须存储在客户端，并且客户端的请求必须是自给自足的。那么...我们如何存储客户端会话？通过互联网搜索，我发现了一些实现这一点的方法。例如：我们向客户端发送包含客户端 id(nick...etc) 的加密令牌，如 token = AES(id, SecretKey);然后我们使用密钥授权用户在服务器上解密令牌的每个请求。任何人都可以提供建议吗？也许还有其他好方法来完成相同的功能。哪种加密算法更适合这个？谢谢。
I'm developing small REST service which should support client session persistence. As you know because of REST we can't store any client data on the server, data must be stored on client side and client's request must be self-sufficient. So...how we can store client sessions? Searching over the internet I've found some methods how to realize this. For example: we send to the client encrypted token which contains client's id(nick...etc), like token = AES(id, secretKey); and then we're authorize user every request decrypting token on the server with secret key. Can anyone advise anything? Maybe there is another good ways to do same functionality. Which crypto algorithm will be preferable for this? Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您提到：
REST 并不是说你不能在服务器上存储客户端数据；而是说你不能在服务器上存储客户端数据。它只是说您不应该在那里存储应用程序状态，您可以将其视为“该客户端正在尝试执行的操作”。
如果您主要尝试拥有经过身份验证的用户的概念，那么标准登录 cookie 就可以正常工作，并且不是“非 RESTful”。
You mentioned:
REST doesn't say you can't store client data on the server; it just says you shouldn't store application state there, which you can think of as "what this client is in the middle of trying to do".
If you are primarily trying to just have a concept of authenticated users, then a standard login cookie will work just fine and is not "unRESTful".
这一切都取决于您对这个问题的回答：为什么您首先需要“会话”概念？
如果您需要确保客户端传递代表一组凭据的 cookie，请考虑让客户端将它们作为 HTTPS 身份验证标头与每个请求一起传递。
如果您需要遵循一些粘性路由规则（以确保客户端的请求发送到特定服务器），请考虑利用这个机会摆脱架构束缚，因为这是扼杀您未来可扩展性机会的最快方法。相反，让您的服务器选择任意。
如果您绝对必须路由到特定节点，请尝试要求客户端传递足够的标识数据，以便您可以使用它来将客户端沿着特定的“泳道”进行散列或分片。例如，您可以根据用户名进行拆分。
It all comes down to your answer to this question: why do you need a "session" concept in the first place?
If you need to ensure that the client passes a cookie representing a set of credentials, consider instead having the client pass them as HTTPS authentication headers with each request instead.
If you need some sticky routing rules to be followed (to make sure that the client's request gets sent to a particular server), consider using this opportunity to get rid of that architectural straightjacket as it is the quickest way to kill your chances of future scalability. Instead, make your server choice arbitrary.
If you absolutely must route to a specific node, try requiring that the client pass enough identification data that you can use it to hash or shard the client down a particular "swim lane". You could split things up based on their username, for example.