判断の出発点
連携は二つのURLではなく二つの業務をつなぎます。交換する記録、項目の責任元、認証、反映時間、停止時の担当者を決めます。試験リクエストが一回成功しても、確認できるのは一部です。
具体例で考える
架空の配送連携で受注、住所訂正、発送、取り消しを追います。社内の注文IDと配送業者のIDを結び付けます。ラベル作成後に応答が消えた場合、再送で二重配送を起こさない方法が必要です。
選択肢とその負担
直呼び出しは即時の応答に、永続キューは利用者が離れても続く処理に、定期照合は漏れの発見に向きます。併用するなら運用担当に分かる状態を示します。
見落としやすい点
提供元固有の項目をアプリ中へ広げず、変換の境界にまとめ、入力を検証します。一時障害と恒久的な住所不備を分けます。間違ったデータを送り続けても回復しません。
記録の契約を業務の言葉で書く
配送では待機、運送会社受付、出荷、取消し、要対応を説明します。共通識別子と許可される遷移を定義します。通信の成功は受領だけを意味し、業務の確定は後から来るかもしれません。すべてのHTTP成功を配送完了として扱わないようにします。
欠落項目、時差、単位、任意値の意味を記録します。空の指示は「指示なし」、項目の省略は「今の値を保持」かもしれません。実際の契約で試し、認証情報の更新、制限、版、試験環境を確認します。未確認回答は確定納期の根拠ではなく、未解決の依存事項とします。
中断した転送に復旧責任者を置く
ラベル作成後に応答を失った場合、対応済み冪等キーや自社参照による検索で解決できることがあります。どちらもなければ二重発送せず調査へ回します。実注文ではなく、ローカルの模擬サービスか許可済み試験環境で確認します。
非公開の運用ツールは失敗参照、安全な分類、最後に確定した状態を示します。再実行は同じ論理識別子と初回同様の検証を使います。認証情報、マッピング変更、日々の例外の担当を決めます。版管理された例と契約テストは外部変更を知らせますが、新しい業務上の意味の扱いには責任者の判断が必要です。
依頼前に確認すること
APIアカウントは誰のものか。代表的な試験環境はあるか。担当者が一件の失敗を見つけ安全に再実行できるか。連携パートナーと正常時も異常時も受入例にしてください。