自由拡張
設計から自分でやってみる
ここまでは、設計図が先にありました。最後は自分で設計するところから始めます。
フリマに足したい機能を 1 つ選んでください。たとえば次のようなものです。
- いいね — 気になる商品に印を付ける
- コメント — 商品に質問を書き込む
- 出品者の一覧 — その人の商品だけを見る
手順は毎回同じ
どの機能でも、進め方は変わりません。第4章から繰り返してきた形です。
プレーンテキスト
1. リソースを決める いいね → likes
2. 表を書く POST /items/:id/like いいねを付ける
DELETE /items/:id/like いいねを外す
GET /items/:id/likes いいねの数を返す
3. 返すコードを決める 201 / 204 / 200 / 401 / 404 / 409
4. 実装する表を書くところまでが設計で、実装はその後です。順番を逆にすると、作りながら形が変わっていきます。
迷ったときの判断材料
設計で迷ったら、これまで出てきた基準に当てはめてください。
| 迷い | 手がかり |
|---|---|
| パスに動詞を入れたくなった | リソースとメソッドで表せないか |
| 一覧が 0 件のとき | 空の配列で 200 |
| ログインが要るか | 誰がやっても同じ結果なら不要 |
| すでにいいね済みだったら | 状態の矛盾なので 409 |
同じ操作を2回されたらどうするか
拡張でよく出てくる問いです。いいねを 2 回押されたら、どうしますか。
選択肢は 2 つあります。
- 409 を返して断る
- すでに付いているので、何もせず成功として返す
どちらも正解です。2 回押しても結果が変わらないようにしておくと、通信が途中で切れて再送されたときに安全です。この性質は、変更系の API を設計するときに何度も出てきます。
手を動かす
演習では、いいね機能を実装します。設計の判断が、コードのどこに現れるかを確かめてください。
要件
POST /items/:id/likeはrequireAuthを掛け、商品が無ければ 404、すでに付けていれば 409- 付けられたら
likes表に記録し、201 で{itemId, likes}を返す GET /items/:id/likesはログインなしで{itemId, likes}を返す(商品が無ければ 404)
入出力例
request("GET", "/items/1/likes") → "200 {"itemId":1,"likes":1}"
request("GET", "/items/999/likes") → "404 {"error":"商品が見つかりません"}"
request("POST", "/items/1/like", null) → "401 {"error":"ログインしてください"}"
request("POST", "/items/1/like", null, "token-tanaka") → "201 {"itemId":1,"likes":2}"
request("POST", "/items/1/like", null, "token-suzuki") → "409 {"error":"すでにいいね済みです"}"
request("POST", "/items/999/like", null, "token-tanaka") → "404 {"error":"商品が見つかりません"}"ヒント
編集 ゆめさく編集部