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 で設計したことの成果です。外の約束を変えずに中を作り替えられるというのが、設計がうまくいっている印です。

手を動かす

演習では、設計図と実物を突き合わせる仕組みを書きます。抜けている行を見つけてください。

1. missing は設計図にあって実装に無いものを、設計図の順で並べる
2. extra は実装にあって設計図に無いものを、実装の順で並べる
3. complete は missing と extra がどちらも空のときだけ true