在这种情况下，在 REST API 中不使用会话的替代方案是什么

Question

我正在为我的 API 控制器使用此方法：

public function register(Request $request)
    {
        // Validation Data
        $validData = $this->validate($request, [
            'user_input' => 'required|regex:/^09\d{9}$/|max:11|min:11',
            'user_full_name' => 'nullable|max:20|min:3',
        ]);
        
        Session::put('user_full_name', $request->user_full_name);
        
        $sms = new SendSms(request()->all()['user_input'],43,request()->all());
        $sms->send();
        
        return response([
            'data' => 'verification code is sent',
            'status' => 200
        ]);
    }

如您所见，我在包含用户名的方法中设置了一个会话：

Session::put('user_full_name', $request->user_full_name);

但这是错误的，因为我没有利用 REST API 的优势，并且 REST 不应该与会话一起提供。

而且我确实需要知道输入的用户名并获取后续步骤的数据，这就是我使用会话的原因。

所以问题是，在 REST API 中合适且标准的替代方法是什么？

Answer 1

我们将会话数据与每个请求一起发送，而不是服务器端会话。这使得通信无状态且可扩展。就技术而言，最简单的是在授权标头中随每个请求发送用户名和密码。稍微复杂一点的是，在使用用户名和密码进行第一次成功身份验证后，服务器会使用用户 ID 等设置不同的值，并使用其私钥对其进行签名。在下一个请求中，客户端可以将用户 ID 与签名一起发回，服务器可以使用公钥检查是否由私钥签名。您甚至可以将签名提供服务与签名检查服务分开。例如，您可以执行类似auth.example.comand 的操作api.example.com，并且api.example.com仅接受签名的内容，但不接受用户名和密码。附加层对用户 ID 和签名进行加密，因此复制它们并添加过期时间将更加困难，因此重放请求将更加困难。签署每个请求是最安全的，但也是最昂贵的方法。还有ofc。你需要 SSL。

在你的大写字母中没有用户ID，因为它是注册。在这种情况下，只需将整个半填写的表单存储在客户端中即可。如果它没有 javascript 或某些服务器端语言，则可能在 cookie 中并将其与验证码一起发送回服务器。

另一种方法是在服务器上创建一个临时事务类型的资源，具有很长的随机 ID，客户端可以知道该资源的 ID，并将事务 ID 与验证码一起发送回。此解决方案需要服务器资源，因此它有点类似于会话管理，但如果您很难将会话完全保留在客户端上并且需要最终一致性、多选项卡表单、多步骤流程等，那么它是一个很好的折衷方案。大写 我宁愿使用第一种方法，除非验证码进入完全不同的通信渠道，如短信、Android应用程序等，并且没有办法或者您不希望他们手动将其输入到客户端，例如进行验证他们需要点击短信中发送到智能手机的链接。