#110 新機能「いいね」を設計から
師範 / 目安 45分
Issue #110 新機能「いいね」を設計から
報告者: 凛(テックリード)
「スプリント最終日。新機能『いいね』を、エンドポイント設計からあなたに任せます。付ける・外す・件数取得。URL・メソッド・ステータス・重複時の挙動——設計表を書いてから実装を。レビューは私が」
ここまでの9件は仕様が決まっていました。最後は自分で決めます。
まず設計表を書く
実装より先です。第4章から繰り返してきた形になります。
| したいこと | メソッド | パス | 成功 | 失敗 |
|---|---|---|---|---|
| 付ける | POST | /items/:id/likes | 201 | 401 / 404 / 409 |
| 外す | DELETE | /items/:id/likes | 204 | 401 / 404 |
| 件数を見る | GET | /items/:id/likes | 200 | 404 |
パスは3つとも同じで、メソッドで動作を分けています。リソースは「その商品のいいね」1つなので、これが REST らしい形です。
重複したときをどうするか
凛さんが名指しした論点です。すでにいいねを付けた人が、もう一度押したらどうしますか。
選べる道は2つあります。
| 選択 | 考え方 |
|---|---|
| 409 で断る | 状態と矛盾する依頼なので拒む |
| 何もせず成功を返す | 結果が同じなら成功でよい |
どちらも正解です。ここでは 409 で断るほうを採ります。押した側に「すでに付いている」と伝わるほうが、画面の表示を合わせやすいからです。
外すほうは逆に、付いていないものを外そうとしても 204 にします。結果として「付いていない」状態は同じだからです。通信が途中で切れて再送されたときにも安全です。
この「同じ操作を2回しても結果が変わらない」性質は、変更系の API を設計するときに何度も出てきます。
完成条件
いいねの3エンドポイントを実装してください。
POST /items/:id/likes— 付ける。201 で{"itemId":1,"likes":件数}。すでに付けていれば 409 ですでにいいね済みですDELETE /items/:id/likes— 外す。204 で本文なし。付いていなくても 204GET /items/:id/likes— 件数を返す。200 で{"itemId":1,"likes":件数}。ログイン不要
付ける・外すはログインが要ります(401)。商品が無ければどれも 404 です。
要件
- 3つとも同じパスで、メソッドによって動作を分ける
- 付けるのは 201、重複は 409、外すのは付いていなくても 204 にする
- 付ける・外すは 401 → 404 の順に確かめ、件数取得はログイン不要にする
入出力例
request("GET", "/items/1/likes") → "200 {"itemId":1,"likes":1}"
request("POST", "/items/1/likes", null, "matsuda") → "201 {"itemId":1,"likes":2}"
request("POST", "/items/1/likes", null, "shiori") → "409 {"error":"すでにいいね済みです"}"
request("POST", "/items/1/likes", null) → "401 {"error":"ログインしてください"}"
request("DELETE", "/items/1/likes", null, "shiori") → "204 "
request("DELETE", "/items/1/likes", null, "matsuda") → "204 "
request("POST", "/items/999/likes", null, "matsuda") → "404 {"error":"商品が見つかりません"}"
request("GET", "/items/999/likes") → "404 {"error":"商品が見つかりません"}"ヒント
前のヒントを開くと次が開きます。開かずに解けると未開封クリアです
ヒント 2ヒント 1 を開くと読めます
ヒント 3ヒント 2 を開くと読めます
編集 ゆめさく編集部