0

最近、残りのAPIについてもっと知るために自己紹介するためにいくつかのチュートリアルを読みました。しかし、私はあちこちでいくつかの疑問を持っており、誰かが私を助けてくれることを願っています.

HTML および REST の初心者向けガイドを読むと、次のように述べられています。

「リソースは名詞として考えるのが一番です。たとえば、次は RESTful ではありません:

1 /clients/add

これは、URL を使用してアクションを記述するためです。これは、RESTful と非 RESTful システムを区別するためのかなり基本的なポイントです。 "

そのため、ユーザーリソースがあり、それにアクセスして通常の挿入/更新/削除/取得を行うような場合に、私は疑問に思っていました

次のようになります。

www.example.com/users [get] <-- すべてのレコードを取得するには
www.example.com/users/1 [get] <-- ID が 1 のレコードを取得するには
www.example.com/users/1 [put ] <-- ID が 1
www.example.com/user/1 のレコードを更新するには [delete] <-- ID が 1
www.example.com/user のレコードを削除するには [post] <-- 新しいレコードを挿入するにはユーザーレコード

これは、要求を行うために 4 つの一般的な動詞を使い果たします。

ログインなどの機能や、一般的には他の種類のアクション コマンドが必要な場合はどうすればよいでしょうか? このような場合、URL はどのように形成され、ルーターはどのようにリダイレクトする必要がありますか?

編集：

さまざまなコメントと回答を見た後。それらからの私の意見は、最終的な解決策は「可能な限り残りの原則を使用し、そうでない場合は関数でクエリ文字列メソッドを使用する」に沿ったどこかになるということです。

しかし、私は実装のわずかな変形 (安らかな実装ではなく、同様の概念に従う) を考えており、このように機能する可能性があるかどうか疑問に思っていました。皆さんがこれについて私にアドバイスしてくれることを願っています。

私が実装する必要があるのと同じ認証/ログイン機能を使用すると、代わりにこれに沿ったものになる可能性があります:

www.example.com/users [get] <-- すべてのレコードを取得するには
www.example.com/users/1 [get] <-- ID が 1 のレコードを取得するには
www.example.com/users/1 [put ] <-- ID が 1
www.example.com/user/1 のレコードを更新するには [delete] <-- ID が 1
www.example.com/user のレコードを削除するには [post] <-- 新しいレコードを挿入するにはユーザーレコード

いつものように、アクションを実行する必要がある場合は、次のようになります。

[controller]/[action] --- user/authenticate [post] --- ログインする
[controller]/[id]/[action] --- user/1/authenticate [put] --- ログアウトする

これは機能しますか？私が直面する予見された問題はありますか?また、このような同様の実装は既にありますか? よろしければアドバイスお願いします！

4

3 に答える 3

1

REST はステートレスなので、すべての必要な情報をすべてのクエリに入れる必要があります。アイデアは、HTTP 動詞 (GET、PUT、DELETE、POST - 既に説明したように) を操作することです。

REST API のユーザー認証が必要な場合は、HTTP Basic Auth などを使用するか、独自の認証を使用します。サーバーへのすべてのリクエストの認証情報を送信する必要があります（ステートレス）。

HTTP 基本認証が必要ない場合は、トークン認証またはその他の認証を試すことができます。

編集：「ログインの確認」リソースが必要な場合は、独自に構築してください。たとえば、http 基本認証ヘッダー情報を使用して GET /account/checklogin を実行します。このリクエストの結果は、認証情報によって異なります。

于 2013-02-05T13:10:20.787 に答える
0

ログインなどの機能や、一般的には他の種類のアクション コマンドが必要な場合はどうすればよいでしょうか? このような場合、URL はどのように形成され、ルーターはどのようにリダイレクトする必要がありますか?

login- actionリソースを持つことは RESTful ではありませんが、login-form リソースを提供することはRESTful です。

/login-form

応答で返す HTML フォームは、コード オンデマンドとして機能します。ユーザーがログイン資格情報を提供できるように構成されたソフトウェアを提供しています。

リソースを単なるものとして識別しても問題はありません/login。例を明確にするためにフォーム部分を追加しました。

Web ブラウザー以外のクライアントのインターフェイスを壊すため、認証が必要なリダイレクトは避ける必要があります。代わりに、次のいずれかを行うことができます。ログインフォームへのリンクを提供します。または実際に応答でログイン フォーム コードを提供します。

認証を管理したい場合は、認証トークンを作成する方法をお勧めします。Web ブラウザーの場合、クライアントが送信する Auth ヘッダーを制御する他の合理的な方法がないため、クライアントが各要求でトークンを提供するのを支援する目的で、単一の Cookieをオーバーロードすることは許容できると思います。明らかに、独自のクライアント アプリケーションを作成している場合、これは問題ではありません。

以下のコメントに答えると、認証トークン シナリオでのログイン フォームの目的は、新しい認証トークンを作成することです。したがって、RESTful に考えて、認証トークンのユーザー リストをモデル化し、認証トークンの表現を POST します。この表現には、ユーザーのユーザー名とパスワードが含まれる場合があります。ユーザーに独自のトークンを選択させるか、ユーザーに代わって選択し、これを応答で返すことができます。アクション-URI は必要ありません。Cookie の設定は、新しい認証トークンの作成が成功した後に行われます。

Amazon S3 REST API の学習をお勧めします。それはあなたの要件とは少し異なりますが、私が見てきた潜在的な REST 認証システムの最も詳細な説明です。

http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAPI.html

RESTful なユーザー管理に関するあなたの考えは正確です。

それが役に立てば幸い ：）

于 2013-02-05T13:10:20.077 に答える
0

真の RESTful な方法でモデル化するのが難しいアクションがいくつかありますが、たとえばログインは、次の擬似コードを使用して実装できます。

GET the user rights whose userID is x and password is y
if (user rights found)
  assign rights to current user
else
  do not assign rights to user

ユーザー権限を取得する方法については、この質問を参照してください。この質問の要点は、通常、リソースにアクセスするには複数の方法が必要だということです。たとえば、ID または既知の属性に基づくものもあります。

  • www.example.com/users/department [get] (部門のすべてのユーザーを取得)
  • www.example.com/users/roleName [get] (特定の役割のすべてのユーザーを取得)
  • www.example.com/users/status/active [get] (「アクティブ」なすべてのユーザーを取得)

ただし、ユーザーにアクセスするいくつかの方法 (特に 2 つ以上のフィルター属性を組み合わせる必要がある場合) は、クエリ文字列パラメーターを使用して管理する方が簡単です。例えば：

www.example.com/users?department=xxx&role=yyy&status=active [取得]

したがって、REST API は次の行に沿って URL を公開する可能性があります。

www.example.com/users?userName=xxxx&password=yyy [取得]

この URL は、ユーザー データベースに対してユーザー名とパスワードのパラメーターを照合し、404 (既知のユーザーと一致しない場合) またはユーザーを表すドキュメントとそのアクセス権を返します。

クライアント コードは、現在のユーザーのセッションを管理します。つまり、ステータスを「ログイン済み」に設定し、セッションをそのユーザー プロファイルに関連付けます。

これを機能させるための鍵は、責任を適切なレイヤーに割り当てることです。API はユーザー セッションを管理する必要はありません。これはクライアント アプリケーションの責任です。それが特にうまくいかない場合があります - ただし、あなたのものかどうかはわかりません.

本当に POST リクエストを使用したい場合は、もちろん、「ログイン」メソッドをそのユーザーのセッションの開始と見なすことができます。したがって、次のようなことができます。

www.example.com/session [POST] パラメータの userID と password を使用します。

これにより、ユーザー プロファイルと権利の表現が返されます。また、URL でアクセス可能なドキュメントを作成する場合もあります。

www.example.com/session/sessionID

www.example.com/session/user/ID/session

ただし、一般に、API 内でセッション状態を管理することは非常に危険な考えです。ほとんどの場合、クライアント セッションは、クライアントと対話する API ではなく、クライアントと対話するアプリケーションによって管理されます。

于 2013-02-05T11:18:36.663 に答える