Rest 概念：系统是否应该对会话的每个请求进行身份验证
Rest Concepts: Should the system authenticate every request of a session
开始从事一个新项目，该项目声称它有 RESTful Api。我看到的一种常见模式是传入的 none 正在被验证。在任何需要的地方，会话对象已被用于获取用户信息。
当我和负责人交谈时，他告诉我，为每个请求创建一个用户会话是非常昂贵的。此实现背后的想法是，当会话对象已经存在时，向数据库发送请求以验证 user.It 非常耗时且不必要。
我只能说它不是 stateless 实现，它违反了 REST 哲学。
不使用此类设计实现的其他实际原因是什么？
当然，它违反了 REST 架构风格。真正的问题是你们中的任何一个是否理解为什么，负责人是否做出了有根据的决定认为权衡是值得的，以及你们是否同意。这是你们两个应该进行的对话的基础。
就我个人而言，我可能建议将身份验证数据保存在数据库缓存中并保持无状态是确保当前性能和未来可扩展性的更好方法，但当然我对系统一无所知。
REST的无状态并不意味着服务器不能存储状态。大多数服务都将大量状态存储在数据库中。使用数据库以外的东西也没有错，比如大多数会话存储都是分布式内存缓存。
无状态的意思是客户端不应该假定服务器记住有关以前通信的信息。每个请求都应包含推断其含义所需的所有信息。
一个典型的例子是 FTP 服务器，它接受像 "cd somedir" 这样的命令。然后假定所有后续操作都发生在该目录中。这在 RESTful 意义上不是无状态的，因为后续消息的含义取决于前一个消息。通过让每个命令都包含其当前工作目录，可以很容易地解决这个问题。
现在，如果您查看您的案例，您会在每个请求中发送一个会话标识符，用于查找身份验证信息。由于此信息在每个请求中传递，您实际上可以在 RESTful 意义上考虑构造无状态。
不要认为你描述的设计有什么问题，它实际上在单页应用程序时代非常普遍。
但要回答您的问题，REST 被定义为无状态的一个重要原因是可伸缩性。当您使用服务器会话存储身份验证信息或任何与服务器相关的存储之王时，您必须在集群环境中跨其他节点维护它。如果您有 2 个以上的节点，它们必须共享或复制 auth 存储（通常是会话），或者强制一个用户与同一节点通信，这称为粘性会话。或者您可以结合这两种技术，这样您就可以关闭一个节点而不影响使用它的用户。
显然，当你拥有真正的无状态 API 时，你不需要这个。在我看来，可以对 SPA 后端使用有状态身份验证，对独立 Web 服务使用无状态身份验证。但是那里没有直线。
开始从事一个新项目，该项目声称它有 RESTful Api。我看到的一种常见模式是传入的 none 正在被验证。在任何需要的地方，会话对象已被用于获取用户信息。
当我和负责人交谈时，他告诉我，为每个请求创建一个用户会话是非常昂贵的。此实现背后的想法是，当会话对象已经存在时，向数据库发送请求以验证 user.It 非常耗时且不必要。
我只能说它不是 stateless 实现，它违反了 REST 哲学。
不使用此类设计实现的其他实际原因是什么？
当然，它违反了 REST 架构风格。真正的问题是你们中的任何一个是否理解为什么，负责人是否做出了有根据的决定认为权衡是值得的，以及你们是否同意。这是你们两个应该进行的对话的基础。
就我个人而言，我可能建议将身份验证数据保存在数据库缓存中并保持无状态是确保当前性能和未来可扩展性的更好方法，但当然我对系统一无所知。
REST的无状态并不意味着服务器不能存储状态。大多数服务都将大量状态存储在数据库中。使用数据库以外的东西也没有错，比如大多数会话存储都是分布式内存缓存。
无状态的意思是客户端不应该假定服务器记住有关以前通信的信息。每个请求都应包含推断其含义所需的所有信息。
一个典型的例子是 FTP 服务器，它接受像 "cd somedir" 这样的命令。然后假定所有后续操作都发生在该目录中。这在 RESTful 意义上不是无状态的，因为后续消息的含义取决于前一个消息。通过让每个命令都包含其当前工作目录，可以很容易地解决这个问题。
现在，如果您查看您的案例，您会在每个请求中发送一个会话标识符，用于查找身份验证信息。由于此信息在每个请求中传递，您实际上可以在 RESTful 意义上考虑构造无状态。
不要认为你描述的设计有什么问题，它实际上在单页应用程序时代非常普遍。
但要回答您的问题，REST 被定义为无状态的一个重要原因是可伸缩性。当您使用服务器会话存储身份验证信息或任何与服务器相关的存储之王时，您必须在集群环境中跨其他节点维护它。如果您有 2 个以上的节点，它们必须共享或复制 auth 存储（通常是会话），或者强制一个用户与同一节点通信，这称为粘性会话。或者您可以结合这两种技术，这样您就可以关闭一个节点而不影响使用它的用户。
显然，当你拥有真正的无状态 API 时，你不需要这个。在我看来，可以对 SPA 后端使用有状态身份验证，对独立 Web 服务使用无状态身份验证。但是那里没有直线。