休憩はリクエスト、動詞、アピケイを取得します

Question

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

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

このようなものを想像してください：/book/1/apikey/s4cr4t！

Answer 1

私の意見では、承認ヘッダーのみを使用する必要があります。それがそこにあるものです。

それをURLに入れるのは悪い考えです。なぜなら：

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

独自の承認スキームの作成の詳細については、 ここ.

Answer 2

資格情報は、を使用して渡される場合があります Authorization ヘッダ：

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

Answer 3

それはすべて、あなたがどこまで行きたいかに依存しますが、メカニズムは同じままです：

環境

目標は、ある程度のセキュリティでクライアントを識別することです。 （注：セキュリティは別の詳細な議論です）。休息の「機能」がステートレスであることを覚えておいてください。つまり、リソースを除いてサーバー上のセッション状態はありません。クライアントをステートレスに保つには、各リクエストでリクエストが独立しているほど十分な情報を提供する必要があります。ユーザー名/パスワード、APIキー、トークンなど、クライアントを識別する方法をサーバーに提供する必要があります。

これを行うためのさまざまなオプションがあるので、ここにいくつかあります：

HTTPヘッダーを追加して、クライアントを識別します

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

クッキーを利用することもできます。 Cookieが含まれている必要があります 情報なし それがサーバー上のステートフルセッションリソースの「ポインターまたはキー」であることを除きます（注：「休憩寿命」のリソースをセッションします）。このリソースを作成して、Response 200 OKまたはPOST（+INFO）を使用してPut（+Info）を作成して、作成された201のResponseと場所： /sessions /123334を使用します。セッションは、タイムアウト、有効なクライアントIPアドレス、APIキーなど、サーバーによって検証できます。

上記の方法を使用すると、Api-Key：xxxxなどの顧客ヘッダーを定義することもできます。しかし、その後、あなたは自分自身を特別なクライアントに制限します。セットクッキーは「よく知られている」ヘッダーであるため、ブラウザはそれらを透過的に処理します。認証プロセスは、リンクをフォローし、フォーム（Put + Post）に記入して認証（セッションリソースの作成）で実行できます。

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

ここでは、あなたもあなたが望むことを自由にすることができます。コンテンツにフィールド/トークン/IDを追加し、サーバーに確認できるようにします。

RESTFUL APIは、リンクを解決することによりアプリケーションフローを実行します。参照してください hateoas と フィールディングの言葉. 。これは、アプリケーションにログインする別のプロセスがある場合にも適用されます。

URISのデータをエンコードしないでください。 （バンド情報から）