RESTなAPIでResourceに対して複数のリクエストを行う場合
ユーザとよく読む雑誌の概念がある場合
※よく雑誌の設定はサイトから提供している雑誌からしか選べないとする。
自分の雑誌しか設定出来ないようにする。っていうアクセス制御が必要だから
以下の様な構成で作った。
提供されている雑誌情報の取得
GET /magazines/
自分の設定している雑誌の取得
GET /my/magazines
よく読む雑誌の設定
POST /my/magazines/#雑誌のID#
よく読む雑誌から削除
DELETE /my/magazines/#雑誌のID#
んでから下のサイトを参考に複数IDを指定できるようにしてみた。
複数のリソースに一度にアクセスしたいときのURL設計 - ぶろぐ。@はてな
Multi-member Resource パターン - リソースモデリングパターン
なんかあんまり、パラメータを指定したくないなーって思って作ってたら
こうなったけど微妙な感じがしてきた・・・・
ユーザブロック関連のAPIを作る
ブロックリスト取得
パターン①
GET /users/#ID#/blocking/
パターン②
GET /blocking/
基本的にブロックリストって自分自身しかアクセスしないわけだから
パターン②がベストなのかなー。
ブロックリストに追加
パターン①
POST /users/#ID#/blocking/
user_id = #ブロックするユーザID#
パターン②
POST /blocking/#ブロックするユーザID#
パターン③
POST /blocking/
user_id = #ブロックするユーザID#
ブロックリストって基本的には、自分自身しか取得も追加も削除も出来ないんだから取得も追加もパターン②がシンプルなのかな〜
って思ってたら、下の記事を見つけた
[REST] 認証が必要な API を REST っぽく作るときのメモ - それはBlog認証が必要な URI は、認証した人から見た URI になるように設計するほうがよい
同じリソースを表す URI はいくつあっても構わず、唯一の URI である必要はないというのが REST の考え方ですので、どういうふうに URI を設計してもよいとは思います。
が、僕の経験上ですが、上のような認証が必要なリソースを表す URI は、認証した人から見た URI として設計するのがよいです。
こうしておくと何が良いかというと、セキュリティを保ったままコードがきれいに書けることが多いからです。
という訳で、
取得：パターン②
追加：パターン②
で実装しようと思う。
REST APIでフォロー、アンフォローを実装するなら
フォローするAPIとして考えたもの
案その一
POST /users/me/following
user_id = フォローする人のID
案その二
POST /users/フォローする人のID/followers
これをどっちにするかってところです。
案その一の場合、
POST /users/赤の他人のID/following
user_id = フォローする人のID
ってアクセスが来たら、赤の他人で勝手にフォローできちゃう＼(^o^)／
まぁ自分のIDの時しか出来ないように弾けばいいんだけどさ。
ちょっと書くの手間だな〜って思ってる。
案その二の場合なら
ログインしてないとダメっていうアクセス制御だけ入れてたら大丈夫＼(^o^)／
フォローする人間のフォロワーに新規追加（自分自身を）みたいな感じになるから自然なのかな〜って書いてて思ってきた。
取り敢えずそうしよう。
