実施日時：2020/3/11
対象範囲：第8章(続き)
参加者：yodai、くめごん、yoridori、まぶり、kassyi

APIの作成では、「登録と参照を分ける」「リソースの単位を分ける」を意識する。
リソースについて、名前、性別、生年月日など、細かい単位で分ける。
影響を最小限にできる。
APIのバージョンの管理は意味が無く、現在の最新が唯一のバージョンとするべき。
古いAPIは段階的に廃棄する。303→404→削除
大きなWebサービスのAPIならばバージョン管理も良いが、単純なAPIでは余り有用でないと思える。
可能な限り複合サービスは、APIを利用する側が開発すべき。
APIを提供する側は、利用する側のアプリケーションを組み立てるための部品の提供に専念するべき。
ドメインオブジェクトとWebAPIでのずれが大きい場合は、変換用の中間オブジェクトを用意した方が良い。
変換などのテクニカル的な関心事をドメインオブジェクトに持ち込むべきでない。
単純なロジックはAPIで行ってもよいが、業務ロジックに関わる複雑なロジックはAPIで行わない。
タイムゾーンはAPIと呼び出し側で意識合わせを密にするべき
APIは基本API,拡張API,個別対応APIの３つに分ける。
それぞれのAPIを利用者に合わせて変更・進化させる。
１つのアプリケーションを複数の小さなアプリケーションに分割したものをマイクロサービスという。
マイクロサービスは、１つのアプリケーションで境界がはっきりして設計が安定したところから別システムに分ける。
複雑なデータの交換が必要となり、メタ情報が必要な場合はXMLが有力。
非同期メッセージングは、送信するアプリと受信するアプリ間で直接接続しない。
注意しないと、メッセージング基盤でメッセージがあふれることがある。
非同期メッセージングは人間同士で電子メールをやりあって仕事することに似ている。