api - REST GET リクエスト、動詞、apikey

Question

柔軟な API Rest サーバーを作成したいと考えています。クライアントが HTTP または APIKEY を使用して認証できるようにします。

私の質問は、apikey を GET リクエストに追加する正しい方法は何ですか? 私の問題は、apikey が URL を汚染することです。

次のようなものを想像します: /book/1/apikey/s4cr4t !

Answer 1

私の意見では、Authorization ヘッダーのみを使用する必要があります。それがその目的です。

URL に入れるのは、次の理由からお勧めできません。

a）あなたが言ったように、URLを汚染します
b）セキュリティのためにSSLを使用することにした場合、APIは引き続きログファイルに表示されます
c）キャッシュは、APIキーごとに1つずつ、同じ表現の複数のコピーを作成することになります.

独自の承認スキームの作成に関する詳細については、こちらを参照してください。

Answer 2

資格情報は、Authorizationヘッダーを使用して渡すことができます。

GET http://domain.com:/book/1
Authorization: apikey="s4cr4t"

Answer 3

それはすべてあなたがどこまで行きたいかによって異なりますが、メカニズムは同じままです:

環境

目標は、ある程度のセキュリティでクライアントを識別することです。(注: セキュリティは別の詳細な議論です)。REST の「機能」がステートレスであることを思い出してください。つまり、サーバー上にリソース以外のセッション状態がないことを意味します。クライアントをステートレスに保つには、リクエストが独立している十分な情報をリクエストごとに提供する必要があります。ユーザー名/パスワード、API キー、またはトークンなど、クライアントを識別する方法をサーバーに提供する必要があります。

これを行うにはさまざまなオプションがあるため、いくつかを次に示します。

クライアントを識別するために HTTP ヘッダーを追加する

ここでは、Authorization ヘッダーを使用して、各リクエストで送信できます。さまざまな認証方式がありますが、Basic Authなどの標準的な方式に固執します。ここでは、おそらく SSL に固執するでしょう。認証プロセスは、必要に応じて一種のトークンを生成します。

クッキーを使用することもできます。Cookieには、サーバー上のステートフル セッション リソースへの「ポインターまたはキー」以外の情報を含めてはなりません(注: セッションは「残りの合法的な」リソースです)。このリソースを作成するには、応答 200 OK で PUT (+info) を実行するか、または 201 Created と Location: /sessions/123334 の応答で POST (+info) を実行します。セッションは、タイムアウト、有効なクライアント IP アドレス、API キーなど、サーバーによって検証できます。

上記の方法で、Api-Key: XXXX などの顧客ヘッダーを定義することもできます。しかし、あなたは自分自身を特別なクライアントに限定します。Set-Cookie は「よく知られている」ヘッダーであるため、ブラウザはそれらを透過的に処理します。次に、リンクをたどり、フォームに入力 (PUT + POST) して認証 (セッション リソースの作成) することにより、認証プロセスを実行できます。

コンテンツ内の識別子をエンコードする

ここでも、やりたいことが自由にできます。コンテンツにフィールド/トークン/ID を追加して、サーバーに検証させるだけです。

RESTful API は、リンクを解決することでアプリケーション フローを実行します。HATEOASとFielding の言葉も参照してください。これは、アプリケーションにログインする別のプロセスがある場合にも当てはまります。

URI 内のデータをエンコードしないでください。(帯域外情報)