RESTのリソースとエンドポイント

このレッスンで学ぶこと

RESTは、扱う対象を名詞のURLで指し、操作をメソッドで分けるAPIの流儀です。この回はその流儀を、攻撃面を描くための地図の読み方として使います。

読み終えるころには、Networkに出たURLを、コレクション・要素・配下の三つに線で分けられるようになります。

RESTはリソースを名詞で指す

多くのAPIはRESTという流儀で作られています。要点は、扱う対象を名詞のURLで指し、それに対する操作をHTTPメソッドで分ける、という点です。対象のことをリソースと呼びます。練習用のショップなら、注文、利用者、出店者がリソースです。

/api/orders             注文の一覧（コレクション）
/api/orders/1043        1043番の注文（一つの要素）
/api/orders/1043/items  その注文の明細
/api/users/57           57番の利用者

コレクションは複数形の名詞、その後ろの数字が個別の要素のidです。スラッシュで下に伸びると「その配下」を意味します。/api/orders/1043/itemsは「1043番の注文に属する明細」です。

形から構造と境界が読める

URLの形が分かると、まだ見ていない先が推測できます。/api/orders/1043が返るなら、/api/orders/1042も同じ形で存在しそうだと読めます。数字のidが連番なら、その前後の注文がずらりと並んでいると分かります。

ネストは権限の境界も示します。/api/sellers/12/ordersは「出店者12に属する注文」で、この形からは出店者ごとに注文が仕切られている設計が読めます。URLは、そのAPIの内部構造を外から言い当てるための、いちばん手軽な資料です。

推測できること自体は穴ではない

ここで取り違えやすい点を一つ。idが連番で推測しやすいことそのものは、脆弱性ではありません。問題になるのは、推測した/api/orders/1042を送ったときに、サーバーが持ち主を確かめずに中身を返してしまう場合です。つまり守るべきは推測の妨害ではなく、リクエストごとの判定です。この判定を外したときに何が起きるかは、続くAPI認可の章で詳しく見ます。

手を動かすときは、練習用の環境で、DevToolsのNetworkに出たURLを書き出し、どれがコレクションでどれが要素か、どこがネストの境界かを線で分けてみてください。

まとめ