現在ログインしているユーザーを取得するには、REST APIでURIが必要です。通常はGETID を持つリソースですが、クライアントはユーザーの ID を認識しません。
以下の解決策を見つけました:
ユーザー名で
このソリューションでは、ユーザーの ID の代わりにユーザー名を使用します。
例：
- ビットバケットRESTAPI:
GET /user/{userSlug}
- ビットバケットRESTAPI:
独自のリソースで
このソリューションには、ユーザー用のリソースが 1 つと、ログインしたユーザー用のリソースが 1 つあります。
例:
ジラRESTAPI:
GET /myselfGitHub REST API:
GET /userスタック エクスチェンジ REST API:
GET /me
シンボリックリンク付き
このソリューションには、ユーザーの ID へのシンボリック リンクがあります。
例：
- コンフルエンス REST API:
GET /user/current
- コンフルエンス REST API:
フィルター付き
このソリューションでは、ユーザー名にフィルターを使用します。
例：
- ジラRESTAPI:
GET /user?username={username}
- ジラRESTAPI:
どれが最も RESTful ですか? 長所と短所は何ですか?
ベストアンサー1
それはあなた次第です。REST の観点から見ると、すべてのアプローチはまったく問題ありません。
ロイ・トーマス・フィールディングの論文*によれば、名前を付けられるあらゆる情報はリソースになり得る:
RESTにおける情報の重要な抽象化はリソース名前を付けることができるあらゆる情報はリソースになり得ます。たとえば、ドキュメントや画像、一時的なサービス (例: 「ロサンゼルスの今日の天気」)、その他のリソースのコレクション、非仮想オブジェクト (例: 人) などです。言い換えると、著者のハイパーテキスト参照の対象となる可能性のあるあらゆる概念は、リソースの定義に適合している必要があります。リソースは、一連のエンティティへの概念的なマッピングであり、特定の時点でのマッピングに対応するエンティティではありません。[...]
/me、、、および類似語を/users/me使用する場合、/users/myself/users/current認証されたユーザーそしてそれは常にコンセプトの認証されたユーザーどのユーザーが認証されているかに関係なく。
柔軟性を高めるために、 もサポートできます/users/{username}。
ちなみに、同様の状況は魔法の (me/self) リソース識別子を使用することは、REST の原則に反していますか?
* RESTに興味がある方は、第5章フィールディングの論文は必読です。