SOAP を REST 化する価値が一番大きいのは、「REST の方が好きだから」ではありません。
本当に強いのは、こういう状況です。
接続先の SOAP サービスはこちらでは変えられない
この瞬間に、facade は便利ツールではなくインフラ寄りの意味を持ちます。
「接続先を変えられない」とはどういう状況か
実際には、だいたい次のようなケースです。
- 政府系・公共系の接続先
- ベンダー管理の ERP や購買システム
- 委託先やパートナーの連携 API
- 別チームが持っていて仕様を変えたがらない社内 legacy service
共通しているのは次です。
- 外側のシステムは政治的に固定されている
- XML contract は壊れやすい
- それでもこちらのチームは今期中に出さないといけない
何がつらいのか
接続先を変えられないなら、複雑さを元から消すことはできません。
その結果、利用側のチームごとに同じことを繰り返します。
- WSDL を読む
- 正しい binding を推測する
- XML envelope を自前で組む
- 認証差分をデバッグする
- SOAP fault を自前で整形する
この重複がいちばん高くつきます。
SOAP-to-REST 層の実務上の役割
接続先が固定されている時、狙うべきは「外部サービスの現代化」ではありません。
自分たちの側に、安全で扱いやすい契約を1つ作ることです。
たとえば次のような状態です。
- 手書き XML ではなく安定した JSON
- 認証とリクエストの整形を1か所で管理
- テスト導線を1つに集約
- 利用側のチームには OpenAPI を渡す
こういう状況では、場当たりの補助スクリプトより、管理された層の方が意味があります。
一回限りの codegen では足りない理由
「とりあえず codegen すればいい」「SoapUI の request を貼ればいい」と考えたくなります。
でも、次の瞬間に破綻しやすいです。
- 接続先の operation が1つ変わる
- 別チームも同じ連携を使い始める
- 環境ごとに認証条件が違う
- 同じ fault が3つの repo で別々に起きる
接続先が自分たちの管理外にあるなら、ローカル修正はローカルに留まりません。
ざっくりした判断基準
もしその連携が、
- 一時的
- operation が少ない
- 担当が1人
- スクリプト1本で終わる
なら、最短のやり方で済ませるのもありです。
逆にその連携が、
- 本番で使われる
- 複数チームが使う
- 外部の固定仕様に縛られる
- 複数のリリースをまたいで残る
なら、SOAP の知識を各所に散らさず、管理された入口を1つ置いた方が自然です。
SOAPless が効く場所
SOAPless の価値がいちばん大きいのは、接続先の仕様をこちらで設計できる時ではありません。
設計できない時です。
つまり勝ち筋は、外部の SOAP サービスと戦うことではなく、その複雑さを自分たちの側で隔離することです。