RESTの考え方
パスに動詞を入れない
API を自己流で設計すると、こうなりがちです。
プレーンテキスト
/getItems
/createItem
/deleteItemById動くのですが、機能が増えるほど名前が散らかります。/getItemsSortedByPrice のようなパスが生まれ、どこに何があるのか分からなくなります。
REST は、この散らかりを止める決まりごとです。考え方は 1 つだけです。
パスは「何に対して」だけを表し、「何をするか」はメソッドで表す。
リソースとメソッドの掛け算
この決まりに従うと、さっきの 3 つはこうなります。
| したいこと | メソッド | パス |
|---|---|---|
| 一覧を見る | GET | /items |
| 1 件を見る | GET | /items/1 |
| 登録する | POST | /items |
| 書き換える | PUT | /items/1 |
| 削除する | DELETE | /items/1 |
パスは /items と /items/1 の 2 種類だけです。あとはメソッドの組み合わせで表しています。動詞をパスから追い出してメソッドへ移した結果です。
この「何に対して」にあたるものをリソースと呼びます。fleama なら商品がリソースです。
2 種類のパス
リソースには 2 つの形があります。
| 形 | 例 | 指すもの |
|---|---|---|
| コレクション | /items | 商品の集まり全体 |
| 個別 | /items/1 | id が 1 の商品 |
POST はコレクションに対して行います。/items に「この商品を仲間に入れて」と頼む形です。PUT と DELETE は、どれを対象にするか決まっているので個別のパスに対して行います。
設計は表から始める
実装の前に、この表を書きます。
プレーンテキスト
GET /items 商品一覧を返す
GET /items/:id 商品1件を返す
POST /items 商品を登録する
PUT /items/:id 商品を書き換える
DELETE /items/:id 商品を削除するこれが fleama API の設計図です。第4章では、この 5 行を上から順に実装していきます。第8章の総合制作では、この表と実物を突き合わせて完成を確かめます。
手を動かす
演習では、やりたいことから、正しいメソッドとパスの組み合わせを導く関数を書きます。表を自分で引けるようにしてください。
要件
listならGET /items、createならPOST /itemsdetailならGET /items/<id>、updateならPUT /items/<id>、deleteならDELETE /items/<id>- そのどれでもないときは
対応していない操作ですを返す
入出力例
designRoute("list", 1) → "GET /items"
designRoute("create", 1) → "POST /items"
designRoute("detail", 3) → "GET /items/3"
designRoute("update", 2) → "PUT /items/2"
designRoute("delete", 7) → "DELETE /items/7"
designRoute("search", 1) → "対応していない操作です"ヒント
編集 ゆめさく編集部