自由拡張

設計から自分でやってみる

ここまでは、設計図が先にありました。最後は自分で設計するところから始めます。

フリマに足したい機能を 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. 実装する

表を書くところまでが設計で、実装はその後です。順番を逆にすると、作りながら形が変わっていきます。

迷ったときの判断材料

設計で迷ったら、これまで出てきた基準に当てはめてください。

同じ操作を2回されたらどうするか

拡張でよく出てくる問いです。いいねを 2 回押されたら、どうしますか。

選択肢は 2 つあります。

1. 409 を返して断る
2. すでに付いているので、何もせず成功として返す

どちらも正解です。2 回押しても結果が変わらないようにしておくと、通信が途中で切れて再送されたときに安全です。この性質は、変更系の API を設計するときに何度も出てきます。

実装の下ごしらえを読む

演習では、重複を探す SQL とルートは準備済みです。まずは仕組みを読んで、設計で選んだ返答がどこで使われるかを確かめます。

複数の条件を両方満たす行を探すときは、WHERE の条件を AND でつなぎます。たとえば会議室の予約なら、部屋だけでなく予約した人も合わせて探します。

const lookupBooking = db.prepare(
  "SELECT room_id, start_time FROM bookings WHERE room_id = ? AND guest_name = ?"
);
const booking = lookupBooking.get(3, "佐藤");

この例では、部屋が 3 で、予約した人が佐藤さんである行だけが見つかります。.get の第1引数は左の ?、第2引数は右の ? に入ります。値は SQL の文字列につなげず、別の引数で渡します。見つからなければ undefined です。

いいねでも、商品と利用者の両方を合わせて確認します。hasLike がその確認を行い、結果を true または false で返します。この回では、準備済みの SQL の役割を読み、返すコードの判断に集中します。

手を動かす

演習では、準備済みのいいね機能を読み、likeStatus の分岐だけを書きます。今回は重複を 409 で断る設計を選びます。初回は 201、同じ人がすでに付けていたら 409 を選んでください。認証と商品の存在確認は先に済ませ、選んだコードに応じた保存と返答は補助関数に任せます。

1. likeStatus に、already によって返すコードを選ぶ分岐を書く
2. 同じ利用者が同じ商品にすでにいいねしていれば 409 を返す
3. まだいいねしていなければ 201 を返す。認証・存在確認・保存・返答は準備済みの処理を使う