fleama API完成
設計図と実物を突き合わせる
第4章で、実装の前に表を書きました。総合制作では、そこへ戻ります。
プレーンテキスト
GET /items 商品一覧を返す 200
GET /items/:id 商品1件を返す 200 / 404
POST /items 商品を登録する 201 / 400 / 401
PUT /items/:id 商品を書き換える 200 / 400 / 401 / 403 / 404
DELETE /items/:id 商品を削除する 204 / 401 / 403 / 404
POST /items/:id/buy 商品を購入する 200 / 401 / 404 / 409
POST /login トークンを発行する 200 / 401第4章の時点では、返すコードは 200 と 201 と 404 だけでした。検証と認証を通ったいま、1 行あたりのコードが増えています。API が丈夫になった分だけ、断り方が増えたということです。
完成の基準は自分で確かめられる
表があると「できた」を自分で判定できます。1 行ずつ、実際に呼んで確かめるだけです。
表に無いものが実装されていたら、それは設計から漏れた機能です。表にあるのに動かないなら、まだ途中です。どちらも表を見なければ気付けません。
抜けやすいのは失敗のほうです
成功する道は、作りながら何度も通るので抜けません。抜けるのは失敗のほうです。
- ログインせずに削除したら 401 が返るか
- 他人の商品を編集したら 403 が返るか
- 売り切れを買ったら 409 が返るか
これらは意識して試さないと通りません。失敗の道こそ確かめてください。
変えていないものにも意味がある
第3章で決めた GET /items の形は、第6章でデータベースへ移っても、第7章で認証が付いても変わっていません。
中身は総入れ替えになったのに、外から見た約束は保たれています。データ層を分けたこと、REST で設計したことの成果です。外の約束を変えずに中を作り替えられるというのが、設計がうまくいっている印です。
手を動かす
演習では、設計図と実物を突き合わせる仕組みを書きます。抜けている行を見つけてください。
要件
missingは設計図にあって実装に無いものを、設計図の順で並べるextraは実装にあって設計図に無いものを、実装の順で並べるcompleteはmissingとextraがどちらも空のときだけtrue
入出力例
checkSpec(["GET /items","POST /items"], ["GET /items","POST /items"]) → {"complete":true,"extra":[],"missing":[]}
checkSpec(["GET /items","POST /items","DELETE /items/:id"], ["GET /items"]) → {"complete":false,"extra":[],"missing":["POST /items","DELETE /items/:id"]}
checkSpec(["GET /items"], ["GET /items","GET /admin/all"]) → {"complete":false,"extra":["GET /admin/all"],"missing":[]}
checkSpec(["GET /items","POST /items"], ["POST /items","GET /items"]) → {"complete":true,"extra":[],"missing":[]}ヒント
編集 ゆめさく編集部