本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。
本日はプレゼンテーション層、いわゆるMVCのViewにあたる部分。
アプリケーション間連携(主にWEBAPIに関して)
要点
- アプリケーション間連携の手法は以下の4つ
ファイル転送
〇 歴史があり、比較的単純で容易
× データのやり取りに関して時間差が発生、ファイル形式を変更しにくい
データベース共有
〇 即時性
× セキュリティ的な部分で好ましくない、プログラムが密結合、データベースの変更は影響度が非常に大きい
WebAPI
〇 広い範囲でのデータのやり取りが必要、データ連携に関しては事実上、標準規格
× 設計の自由度が高く、適切な設計判断が難しい、APIの変更が難しい、同期型なので制約になることが多い
メッセージング
〇 非同期なので相手の都合に左右されない
× 比較的設計が困難 - WEBAPIでは通信方式はHTTP通信、文字コードはUTF8,データ形式はJSONorXML、できることはデータの取得と登録
- 要求対象はURL、要求の種類はHTTP、処理結果をステータスコードで返し、データはJSONかXMLで。
- リソース名はスキーム://ホスト名/リソースへのパスが一般的
例 https://api.example.com/books/1234 - 要求種類はGET,POST,PUT,DELETE
- GET句ではクエリパラメータを渡して、対象リソースを取得する
- POSTとPUTの違いは事前にデータの仕様を知っているか否か(PUTは知っていなければいけないので密結合になる)
- 一般的にはPOSTのほうがアプリケーション間連携の独立性が高くなる
- DELETEもアプリケーション間の密度が高くなるため、あまりお勧めできない
- パラメータの個数が多かったり、データの項目数が多いものは一般論でいえばアンチパターン
- 基本の設計方針は参照と登録を分ける、リソース(データのかたまり)の単位を分ける
- 例えば登録時のレスポンスで予約内容を返す、を同時に行うと複雑になるため、登録は登録だけ、そのあと別途参照のAPIを使う
- 参照でもデータをうまくカテゴライズ化、階層化する
感想
データ連携は現在でいうとやはりAPIが主力だと思いますが、色々な手法の良いところ、悪いところを列挙して整理してあげているとわかりやすいですね。
メソッドはGETとPOSTしか使ったことがありませんでしたが、
一般的には取得(GET)、新規登録(POST)、更新(PUT)、削除(DELETE)でしょうか。LaravelだとすでにこれらがインストールされているのでAPIを作るのが非常に楽です。
