よくない連携の癖があります。
SOAP fault を、そのまま公開 API の仕様の一部として扱ってしまうことです。
もし利用側の各チームが次を理解しないといけないなら、
soap:Clientとsoap:Serverの違い- envelope parse error
- namespace mismatch の症状
- WCF や ASP.NET の例外文字列
それは「システムを単純化した」のではなく、「痛みを外へ押し出した」だけです。
ここでいう責任分界とは何か
連携層を持つチームの仕事は、単にリクエストを中継することではありません。
どの複雑さを上流側の事情として吸収し、どこから先を他チームへ渡すかを決めることです。
生の SOAP fault は、吸収すべき側に入ります。
そのまま流すと何が高くつくのか
SOAP fault をそのまま流すと、利用側のチームごとに次を解くことになります。
- この fault は何を意味するのか
- 自分たちのバグなのか上流のバグなのか
- 再試行すべきか
- どうテストすべきか
- オペレーターやユーザーに何を見せるか
同じ連携コストを、チームごとに何度も払い直す形です。
望ましい境界
健全な連携境界は、だいたい次の 3 つをやります。
- fault の形をそろえる
- 診断に必要な情報は残す
- XML 固有の事情を無関係なチームへ漏らしすぎない
全部を隠すという意味ではありません。利用側が行動しやすい形に翻訳する、という意味です。
SOAPless が効く場所
SOAPless はこの責任分界と相性がいいです。今ある機能だけでも、
- 正規化された
soap_faultresponse - ダッシュボード上の
Test Operation - オペレーションのスキーマ確認
- WSDL 更新後の仕様確認
が揃っています。
その結果、利用側のチームは、生の SOAP エラーの出方を暗記する代わりに、JSON と整理された挙動を前提に開発できます。