釣りキチプログラマー翔平の備忘録 
はじめに
現場で役立つシステム設計の原則第８章 アプリケーション間の連携を読んで、
今まで現場で設計をしてきた自分の観点で、
特に重要だと感じたポイント、気付き、今後参考にしていくべきだと感じたことをまとめてみました。
現場で役立つシステム設計の原則を読んでみて、
今後現場で取り入れたいこと、気付きなどなど
まとめ記事を作ったので是非こちらも見てください！！
現場で役立つシステム設計の原則から学んだことや気づきまとめ
現場で役立つシステム設計の原則第８章を読んでの気付きなど
８章はAPIのインタフェース、１本のAPIの役割を大きくしすぎない工夫
といった内容の話が中心の章でした。
本に出てくるよくない例は、
きっちり今までの現場で出会して困ったことがありました、、、
今後のIF定義、１つのAPIでどこまでやらせるか？？
といったことを考える際に参考にしたいと思うような内容でした。
それでは、印象に残った箇所を紹介していきます。
アプリケーション間の連携パターン４つについて｜ファイル転送〜API連携〜メッセージングなど
アプリケーション間の連携には以下４つがある。
- ファイル転送
- データベース共有
- Web API
- メッセージング
ファイル共有が一番設計が簡単で、
メッセージングが一番設計や運用が複雑。
ただ、人の普段の行動は例えばメール送受信を考えても、
非同期で受け取り側のタイミングで取得する。
というような内容を本で述べられていました。
メッセージングの話は以前勉強会で同じような話がありました。
「実践！インテグレーションパターン」(勉強会)に参加してみた感想や気づきなど
最近はメッセージング基盤が簡単に利用できるのでこの方式は
今後さらに採用されるケースが多くなるのではということだったので勉強しなくてはと思います。
自分は今までの現場ではメッセージング以外のパターンは全て経験がありますが、
非機能用件などで問題ない場合はこちらの検討もしていきたいなと思います。
RestAPIはPOSTやGETを使いPUTやDELETEは極力使わない
POSTとPUTは同じ登録を依頼するもの。
違いは、
POSTは登録を依頼する(識別番号はAPIが発番)だけ。
登録成功すれば201 Createdを返却する。
PUTは識別番号指定で登録を依頼する。
識別番号のものが存在しなければ新規登録して201 Createdを返却し、
存在すれば既存更新して200 OK、204 NoContentなどを返却する。
PUTの場合識別番号を事前にAPI利用側が把握したり、
返却されるステータスによるハンドリングを考えたり
とアプリケーション間が密結合になりがち。
更新もGETとPOSTの組み合わせで実現し、
API利用側に更新されたのか新規登録したのかを意識させることなく、
登録の依頼だけさせた方が良い。(DELETEも同じイメージ)
という記載がありました。
僕は更新はPUTで登録はPOST、削除はDELETEと考えていたのですが、、、
システム間の結合度を考えるとあんまり良くなかったのかと気付きました。
確かに、PUTのAPIを作るとAPI提供側で場合わけが無駄に必要になるし、
そうなると利用側もそれを受けてハンドリングも複雑になるし・・・
勉強になりました。
大は小を兼ねるAPIはAPI提供側・利用側共に不幸になる
リクエストパラメータが数十個あるとか、
レスポンスパラメータが数十個ある。
どんなリクエストにも対応できる。
(パラメータを積めるケースやnullでリクエストするケースなどなんでもありAPIだから)
ということをすると、
API提供側はパラメータが入ったり入らなかったりする際のハンドリングが複雑になり、
API利用側もAPIをどう使うのか理解するのに時間がかかったり、使い方を誤ったり、
誤った使い方をされないようにAPI提供側がガチガチにチェックを入れたり・・・
カオスになる。
という記載がありました。
こういうAPIばかりといままで出会ってきました、、、
登録が目的なのに、後処理でいろんなデータをかき集めてレスポンスで返してやるAPIとか、
APIもドメインモデルでの設計と同じように、
小さく汎用的に作るという考え方が必要で、
それを組み合わせるAPIは必要に応じて作る。
(本来はAPI利用側で組み合わせるべきだがどうしてもという場合のみ)
こういう考え方がAPIを設計する際には重要なのだと学びました。
小さいAPIでいろんなことをさせない、
リクエストパラメータもレスポンスパラメータも数個くらい。
こうすれば汎用的に使え、使う側も迷わないので良くわからないチェック機能も不要なので
シンプルになります。
まとめ
現場で役立つシステム設計の原則第８章 アプリケーション間の連携を読んで、
この辺りは自分の経験的に重要だなと感じたので、
普段から意識して現場での作業をしていこうと思います。
- アプリケーション間の連携パターン４つについて｜ファイル転送〜API連携〜メッセージングなど
- RestAPIはPOSTやGETを使いPUTやDELETEは極力使わない
- 大は小を兼ねるAPIはAPI提供側・利用側共に不幸になる
大は小を兼ねるAPIは今まで散々苦しめられたので、、、
今後はもう２度と不幸にならないようにしていけたらと思います。。。
