はじめに
APIでよく /users/{userId} とかありますよね。例えば GET /v1/users/{userId}/images で userId のユーザーが投稿した画像一覧が取れる、とかです。
ここで例えば、「ログインユーザーの画像一覧がとりたい」という場合がありますね。例えばマイページを開いた際に過去自分が投稿した画像一覧を見られるという場面があるかとおもいます。想像できない人はインスタグラムのアプリでも触ってみるといいでしょう。
さてここで、自分の投稿した画像一覧を取ってきたければ {userId} の部分にログインユーザーのIDを入れたらいいわけです。しかしここで一つ疑問があります。
まずマイページに行くにはログインしていることが必須ですよね。であればcookieやアクセストークンなどをユーザーは持っているはずです。仮にcookieを持っていたとしましょう。cookieが送られてきたらサーバーサイドは対応するユーザーの情報を取れるはずです。であればわざわざAPIにuserIdをつけてもらわなくてもいいじゃないか。
そこて誕生するのが GET /v1/me/images のようなAPIです。me というのは users/{userId} のエイリアスです。こうなると次に疑問が生じるのは user/{userId} と me とどちらがいいの？という点になります。
user/{userId} と me の違いは
考えなくていけないのは、 user/{userId} と me って本当に同じものなの？ということです。
ここで重要なのは、「自分にしか見えない情報があるかどうか」です。例えば先程の images で考えましょう。imageには「公開」と「非公開」があり、非公開のものは投稿者しか見えないものとします。非公開の画像は他の人から見たときには見えないようにする必要があります。
さて、どう実装するでしょうか。
/v1/me/imagesでアクセスした場合は非公開の画像が帰ってくるようにする。/v1/users/{userId}では非公開の情報は（たとえ本人によるアクセスでも）帰ってこない/v1/users/{userId}で本人によるアクセスの場合のみ非公開の情報を返す
一見どちらでもいいような気がします。
では次のような場合は
ここまでだと一見どちらでもいいような気がしますが、2の方法を取った場合に次のような場面で苦労しました。
「自分のプロフィール表示を確認するページを作成したい」
この場合は me と users/{userId} が別れているほうが便利なのです。2の方法を採用すると、自分の表示を確認する場合にどうやっても非公開の情報までとれてしまうので面倒なのです。
結論
/me というエンドポイントは便利なので使っていこう。単に自分の情報が取れるというだけでなく、本人しか見られない情報を取得したい場合とかに便利！
