在这种情况下，您在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不应随附会议。

而且，我确实需要知道输入的用户名并在下一步获取该数据，这就是为什么我使用会议的原因。

因此，问题是做这件事的替代方法是什么合适的＆amp; REST API的标准？

Answer 1

而不是服务器端会话，我们将会话数据与每个请求一起发送。这使得通信无状态和可扩展。根据技术，最简单的是在授权标题。更复杂的是，在使用用户名和密码进行第一次成功身份验证之后，服务器设置了一个不同的值，例如用户ID并使用其私钥签名。在下一个请求中，客户端可以将用户ID与签名一起发送回签名，并且服务器可以使用公共密钥检查是否由私钥签名。您甚至可以将签名提供服务与签名支票服务分开。因此，例如，您可以执行auth.example.com和api.example.com和api.example.com仅接受auth.example.com 签名的内容，但没有用户名和密码。一个额外的图层正在加密用户ID和签名，因此很难复制它们并添加到期时间，因此很难重播请求。签署每个请求是最安全的，但最昂贵的方法是这样做的。和OFC。您需要SSL。

在您的大量情况下，没有用户ID，因为它是注册。在这种情况下，只需将整个填充表格存储在客户端即可。如果它没有JavaScript或某些服务器旁语言，则可能在cookie内部，并将其与验证代码一起发送回服务器。

这样做的另一种方法是使用非常长的随机ID创建服务器上资源的临时交易类型，并且客户端可以知道资源的ID，并将交易ID与验证代码一起发送回交易ID。该解决方案需要服务器资源，因此它与会话管理有些相似，但是如果您难以将会话完全保留在客户端，并且当您最终需要一致性，多标签表单，多步骤过程等时，这是一个很好的妥协。高层情况我宁愿使用第一种方法他们需要单击链接到达智能手机的SMS。

Answer 2

如果您要求使用JSON Web令牌（JWT）的Laravel Passport或Sanctum。 JWT是用于API保护的常见标准，我不会写一些有关如何做的教程，因为有很多。

Answer 3

首先，我不建议使用无效数据进行任何形式的验证。这来自您的验证上下文，我相信您应该制作'user_full_name'=＆gt; “必需”，因为您将使用它进行验证。

其次，我认为会话或任何替代方案不是解决这种情况的好方法，我宁愿使用Auth Middleware保护验证路线，发行并返回圣所api令牌

$token = $request->user()->createToken($request->user_full_name);
return response([
        'data' => 'verification code is sent',
        'token' => $token
        'status' => 200
    ]);

然后，我将使用用户进入授权标头的令牌来检索用户代码，然后检查针对已发送代码的代码进行验证。 （我也会坚持验证代码）。

Answer 4

我只是想分享有关这个问题的一些想法。

从严格的“无状态”角度，使用会话或通过每个请求中的身份验证字段仍在使用会话。

如果您要处理一个过程，那么一系列的状态下一个领导/喂食的状态，这并不是真正的“无状态”过程。

但是，如果您只是为了提供资源，那么可能是一种真正无状态的方法。

---

但是，无论您如何切片，一个过程都需要状态。唯一的问题是，它在何处，验证了它以及有关如何从您的服务运输的细节。

cookie，JWT甚至URL编码状态都不是无状态的，这只是您选择如何建模该状态如何传输，摄入和维护该状态的问题。

---

因此，可以说，您当前的解决方案不是“错误的”，这只是在请求之间管理应用程序状态的一种可能实现。

如果您的应用程序在浏览器中运行而不是命令行，则每次请求都会自动获得cookie，标题和会话，因此您应该随时使用它们。

但是，如果您使用的是AJAX请求，则必须在其中手动提供/定义标题并维护会话，那么是的，您可能需要使用JWT或其他方法对状态进行建模。

---

至于如何在不重新验证其字段的情况下对用户数据之间的数据保持认识，这正是令牌的目的。

然后，您将在请求之间传递这些令牌，然后通过使用任何相关记录引用令牌来检索字段。

然后，您将管理应用程序服务器/服务中该令牌的寿命/费率限制。

---

无论如何，也许这很有用，洞察力。

Answer 5

我猜想您需要该值，即以后将从API烘烤的函数（另一个请求），但信息不完整。如果需要，可以选择几个替代方案。一个人将该值返回给客户端，因此可以在随后的API调用中使用。另一个是将数据存储在数据库中，并使用一些ID或令牌存储，并在响应中返回该ID或令牌，以便客​​户端可以在随后的API调用中使用它，您可以使用该值从数据库中检索数据。

当下一个API调用需要大量数据时，第二种方法会更好。对于几个数据点，第一位导师更好。