4

当使用必须验证的电话号码执行身份验证时，如何处理 RESTful 身份验证？

例如，假设用户想要登录。用户将使用电话号码点击端点，然后将文本消息排队以发送到该电话号码以进行验证。

理论上，这两个端点可能如下所示：

身份验证 [POST /users/authentication]

使用电话号码查找或创建用户，返回该用户，并将要发送到指定电话号码的文本消息排入队列（延迟）。

  • 请求（应用程序/json）

    {
    "phone_number": "4151111111"
}

  • 响应 200（应用程序/json）

    {
    "id": "85165292-8cce-42a3-960a-ffbc7dac987b",
    "name": "James",
    "avatar_url": null,
    "phone_number": 4151111111
}

组验证

用户提供在短信中发送的验证码，以验证请求身份验证的用户是否有效。

验证 [POST /users/{id}/verification]

  • 请求（应用程序/json）

    {
    "phone_number_verification_code": "1234"
}

  • 响应 200（应用程序/json）

    {
    "id": "85165292-8cce-42a3-960a-ffbc7dac987b",
    "name": "James",
    "avatar_url": null,
    "phone_number": 4151111111,
    "auth_token": "ff6828134dd6b2d288qcb8f381b0657c"
}

以 RESTful 方式进行此验证的惯用方式是什么？动词正确吗？端点名称是否正确？我错过了什么吗？

4

1 回答 1

4

问题中缺少一些信息。资源“用户”是否已经在服务器上创建，只是要验证电话号码吗？

假设“是”。以下方案对我来说看起来不错：-

验证

要求

POST /users/<uid>/phones
{
  “phone”: “4151111111”
}

添加新资源时应使用响应 201（已创建）。在这种情况下，会创建一个新的电话号码，因此应返回 201。

阅读规范以获取更多信息http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5

根据 REST 规范，POST 方法应添加子资源。而GET方法应该列出URI所代表的资源下的子资源。

根据这些 REST 规范进行设计，对同一 URL 执行 GET 可能会返回电话号码列表。这不是强制性的，但根据 REST 语义它应该是这样的。所以一个 GET 请求/响应应该是这样的，

要求

GET /users/<uid>/phones

响应 200 确定

{
  “phones”: [
    {“phone”: “4151111111”, “verified”: “no”},
    {“phone”: “xxxxxxxxxx”, “verified”: “yes”},
    …
  ]
}

用于验证

现在您已经在服务器上拥有一个由 URI (/users//phones/4151111111) 标识的资源。只是没有经过验证。要验证它，请直接向资源发送帖子消息。像这样

要求

POST /users/<uid>/phones/4151111111
{
  “code”: “1234”
}

响应 200 好的。

现在“电话”上的 GET 将返回“已验证”：“是”。像这样，

要求

GET /users/<uid>/phones

响应 200 确定

{
  “phones”: [
    {“phone”: “4151111111”, “verified”: “yes”},
    {“phone”: “xxxxxxxxxx”, “verified”: “yes”},
    …
  ]
}

如果尚未创建“用户”，那么您也可以为用户使用类似的语义。像这样。

获取/用户

POST /users，带有有效负载以添加新用户。响应 201（已创建）等。

更新

如果用户存在或者是新用户，则请求可能在 URL 中没有“用户”，如下所示，

POST /phones
{
  “phone”: “4151111111”,
  "user": "James"
}

响应可能是 201（已创建），但我们还必须注意用户是否已经存在。当发送电话号码时，可以在 DB 中搜索匹配的用户，并根据不同的条件返回这样的响应，

情况1，用户不存在

HTTP/1.1 200 OK

{
   "rel": "/phones/4151111111",
   "phone": "4151111111",
   "verified": "no"
}

案例2，用户存在但手机未验证

HTTP/1.1 200 OK

{
   "rel": "/phones/4151111111",
   "phone": "4151111111",
   "verified": "no"
}

请注意，案例 1 和 2 的响应相同。在案例 1 中，在服务器上创建了一个用户。

案例 3，用户存在且手机已验证

HTTP/1.1 200 OK

{
   "rel": "/phones/4151111111",
   "phone": "4151111111",
   "verified": "yes"
}

在案例 3 中，用户已经存在并且电话已经过验证；所以客户端应该发送一个 GET 请求，而不是再次发送带有验证码的 POST。客户端应该自动重定向而不是用户发起 POST。

案例 4，电话已经存在，但已链接到其他用户。在这种情况下，返回错误代码或根据您的应用程序要求。

在响应中发送 URI 尊重 RESTful 样式的“按需代码”语义。客户不需要事先知道在哪里进行验证。

为了验证，现在客户端会将在文本消息中收到的代码 POST 到先前响应中返回的 URI。像这样，

POST /phones/4151111111
{
  “code”: “1234”
}

响应可能是 201（已创建），因为还添加了新电话或 200 以及所需的响应正文。

于 2014-10-15T10:35:33.507 回答