はじめに
こんばんは。
現在 現場で役立つシステム設計の原則 という本を読んでおります。
前回
読んだ感想を備忘録で残しておきます。
今回は8章です。
8〜10章を全部読んでこれで終わりにしようと思いましたが、8章が意外とボリューム大きかったので、8章だけにしました。
本題
8 章 アプリケーション間の連携
アプリケーションとアプリケーションをつなぐ
アプリケーション間の連携の種類が以下の4つ。
- ファイル転送
- データベース共有
- Web API
- メッセージング
それぞれのメリット・デメリットが述べられていた。
Web APIのしくみを理解する
迷いやすいPOSTとPUTの違いをわかりやすく説明してくれていた。
POSTは識別子を指定せずとも登録ができること
PUTは識別子を指定して登録ができること
識別子を指定するぶん結合が密になってしまう。なのでできるだけ登録・更新はPOSTで行うべき。
本によると PUTと同じ理由で DELETEもできればPOSTで行うべきということだった。
良いWeb APIとは何か
One Size Fit All = 「大は小を兼ねる」
いろんなパラメータを指定できて、様々な情報を取得できるAPI。
ただ、利用者側から見ると、それは良いAPIではなく 利用する側の負担が大きいAPI となる。
単純な取得に関しても、指定できるパラメータを理解しなければいけないし、様々な情報から必要な情報を選んだりする必要がある。
また、提供側もパラメータごとに条件分岐が出来るので、どちらにとっても幸せではなさそう。
微妙に異なる様々なニーズを一つのAPIで叶えようとしてしまった結果、出来上がってしまうパターンが多い。
Web API は以下の2通りの意味で使われている
- 利用する側でアプリケーションを組み立てるための部品のセット
- 利用する側でプログラミングせずに利用できる完成品
完成品 = Webサービス
部品 = Web API
ということだが、部品として粒度が大事になってくる。
小さい方がいろんな工夫ができ、かつ、実装も単純だと思う。ただ、小さいため、組み立ての難易度は高くなってくる。
良い Web APIとは、組み立ての多様性を維持しつつ、組み立ての負担が増えすぎない適切な大きさの部品を用意することです。
発展性に富んだAPI開発のやり方
- 登録と参照を分ける
- リソース(データのかたまり)の単位を分ける
この2つを常に意識することが良い Web APIの発見につながります。
例で提示してくれていた予約システムのAPIだが、自分はWebサービス的なAPIを選んで作ってしまっていた。
ただ、再度取得のAPIを投げるためのコストはこの場合考えないのだろうか?
そこだけ知りたい。
また、よくある /api/v1 みたいなバージョン管理も、APIを小さな部品として作っていれば、部品の追加と削除ですむので、バージョンを分ける必要がないとのこと。
これは、自分も思ってたので納得。
ドメインオブジェクトとWeb API
ドメインオブジェクトは、ロジックが軸にあり、APIから送られてくるデータは、データが軸にあるので、そのままズドンと変換はできない。
また、ドメインオブジェクトが期待しているデータがAPIからすべて送られてくるとも限らない。
そのような場合はRespons用のクラスを一枚噛ませれば良い。
また、単純なものであれば、そのまま変換しても良い。
大事なのは、ドメインオブジェクトの関心事がAPIによってぶれないこと。
複雑な連携に取り組む
マイクロサービスの説明や、メッセージングでの連携手法について詳しく説明されていた。
また、結構重要だなと思ったのは、APIのグルーピングが複雑な連携に取り組むためには必要というところ。
個別・共通・汎用みたいにグルーピングをし、それを管理し整理していく。
短期的にはコスト要因だけど、長い目で見ると関係者全員の利益になると本でも言われている。
終わりに
次は9〜10章を読みます。
次こそ終了っぽい。
現場からは以上です。
