4

検証が必要な電話番号で認証が実行される場合、RESTful 認証をどのように処理しますか?

たとえば、ユーザーがサインインしたいとします。ユーザーは電話番号でエンドポイントをヒットし、確認のためにその電話番号に送信されるテキスト メッセージをキューに入れます。

理論的には、2 つのエンドポイントは次のようになります。

認証 [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 (Created) は、新しいリソースが追加されたときに使用する必要があります。この場合、新しい電話番号が作成されるため、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 OK

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

検証用

これで、URI (/users//phones/4151111111) で識別されるリソースがサーバーに既に存在します。検証されていないだけです。確認するには、投稿メッセージをリソースに直接送信します。このような

リクエスト

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

応答 200 OK。

"phones" に対する GET は、"verified": "Yes" を返すようになりました。このような、

リクエスト

GET /users/<uid>/phones

応答 200 OK

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

「ユーザー」がまだ作成されていない場合は、ユーザーにも同様のセマンティクスを使用できます。このような。

GET /ユーザー

POST /users、新しいユーザーを追加するためのペイロード。応答 201 (作成) など

アップデート

ユーザーが存在する場合、または新しいユーザーである場合、リクエストは次のように URL に「users」が含まれていない可能性があります。

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

応答は 201 (Created) になる可能性がありますが、ユーザーが既に存在するかどうかにも注意する必要があります。電話番号が送信されると、一致するユーザーが 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 では、ユーザーがすでに存在し、電話が確認されています。そのため、クライアントは確認コードを含む POST を再度送信する代わりに、GET リクエストを送信する必要があります。ユーザーが POST を開始する代わりに、クライアントが自動的にリダイレクトする必要があります。

ケース 4、電話は既に存在しますが、他のユーザーにリンクされています。この場合、エラー コードを返すか、アプリケーションの要求に従ってください。

応答として URI を送信すると、RESTful スタイルの「コード オン デマンド」セマンティクスが考慮されます。クライアントは、検証する場所を事前に知る必要はありません。

検証のために、クライアントは、テキスト メッセージで受信したコードを、前の応答で返された URI に POST します。このような、

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

新しい電話も追加されているため、応答は 201 (作成済み) になるか、必要な応答本文を含む 200 になります。

于 2014-10-15T10:35:33.507 に答える