0

API のリソースを着実に構築していますが、RESTful API を構築する正しい方法について多くの調査を行った結果、「複雑な」リクエストを受信する方法の例を見つけることができませんでした。

たとえば、ログイン プロセス (認証キーの更新にすぎません) の一部として、次の URI がクライアントによってディスパッチされます。

/api/auth/login

URI に値はありません。リソースは/auth/で、トリガーされるコマンドは です/login/。実際のログインの詳細は、サーバーの Authorization ヘッダーに送信されます。

さて、私がこの質問をするようになったのは、キーの有効期間をクライアントが確認できるようにするコマンドを書いていたときに、すぐに getkeyexpirationコマンド名またはそれに似たものに惹かれました。

突然、これは 6 つの制約で読んだものとは違うと感じました。これは操作呼び出しのように感じます。

では、上記の例に基づいて、これはまだ RESTful API ですか? URI リソース名と追加された値を使用するだけではこれを実行する方法が思いつかないので、私は心配しています。

ありがとうございました

編集：

これを読んでから：http://blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http

リソースに名前を付け、リソースに名詞のみを使用することで、サーバーがどのように動作するかのコンテキストがより明確になることを理解し始めています。

上記の例について：

/api/auth/login

リソースのコンテキストであるため、ログインのプレフィックスとして auth を使用しました。システムを拡張できるように設計しており、URI レベルでリソースを分類する方法が必要です。これを行う標準的な方法はありますか？

4

1 に答える 1

1

HTTPは動詞を提供するため、RESTfulリソースは名詞である必要があります。

代わりに、次のようなものを提案します。

/api/key

次にPOST、（HTTP Authorizationヘッダーを含めて）新しいキーを作成し、次のようなものを返すことができます。

/api/key/1234ABCDBLAHBLAH

これはセッションに固有のキーであり、GETを使用して、有効期限などの詳細を取得できます。もちろん、後続の各リクエストでそのキーを渡す必要があります。

RESTful APIのコンテキストで説明したときに重要なものが不格好に聞こえる場合、それは通常そうであるためです。セッションは人間/ブラウザーの概念ですが、RESTfulAPIはアプリケーション/統合の概念です。

サーバーは他のサーバーに「ログオン」しないため、これは疑問を投げかけます。呼び出し元にAuthヘッダーをログインAPIに渡すように要求しても問題がない場合は、API呼び出しごとにAuthヘッダーを渡すように要求しないのはなぜですか。キーの概念を完全に忘れますか？

于 2012-10-31T19:32:00.253 に答える