フロントエンドの現場で SOAP が出てくると、最初に出る発想はだいたいこれです。
REST に変換してブラウザから叩けるようにすればよさそう
方向性としては合っています。ただし、本番でつらくなるのは XML だけではありません。
- CORS
- API key をどこに置くか
- session / credential の境界
- allowlist
- 顧客や監査部門から見たドメインの扱い
つまり、問題は SOAP だけではなく、ブラウザ配信でもあります。
なぜフロントエンドは REST 化したいのか
フロントエンドチームが嫌がっているのは、だいたい次の要素です。
text/xmlSOAPAction- namespace
- WS-Security header
- ちょっとした型ズレで壊れる envelope
欲しいのは次です。
- JSON
- OpenAPI
- method ごとの分かりやすい挙動
- サンプル付きのテスト導線
ここまでは完全に正しい要求です。REST 化された入口を置けば、その契約はかなり扱いやすくなります。
でもブラウザが入ると話が変わる
ブラウザから直接呼ぶとなると、問題はメッセージ形式だけではなくなります。
同一オリジン制約があるので、アプリ本体と API の origin が違えば、サーバー側が適切な CORS header を返し、場合によっては preflight にも応答しないといけません。MDN が整理している通り、fetch() は cross-origin の呼び出しをそのまま許してくれません。
実際の論点は次になります。
- その origin から呼べるのか
Authorizationや custom header で preflight が発生しないか- credential を安全に扱えるか
- API key をブラウザ側に置いてしまわないか
REST 化した入口だけで足りるケース
次の条件なら、SOAP-to-REST の入口だけで十分なことが多いです。
- 呼び出し元がサーバー側
- すでにバックエンドがある
- BFF パターンを採っている
- secret をブラウザに出さずに済む
この形なら、フロントエンドは JSON を受け取りつつ、認証や origin の扱いはサーバー側に閉じ込められます。
それでも BFF を挟んだ方がいいケース
次の条件では、薄くても BFF を1枚挟む方が安全です。
- ブラウザが本番 API key を持つことになる
- オペレーション単位ではなくユーザー単位の認可を入れたい
- 顧客や審査側が same-origin に近い構成を求める
- 複数の upstream をまとめて 1 つのレスポンスにしたい
これは大げさな設計ではありません。ブラウザ都合の問題を連携層に持ち込まないための整理です。
SOAP を REST にしても、境界は消えない
REST 化で消えるのは XML の痛みです。ブラウザの security boundary までは消えません。
なので、本当に聞くべき質問はこれです。
SOAP を REST にできるか
ではなく、
REST 化したあと、誰が、どこから、どんな認証で呼ぶのか
です。
実務上の判断基準
REST 化した入口をそのまま使いやすいのは:
- バックエンドから呼ぶ
- 社内自動化が credential を持つ
- 主目的が JSON 化とテストしやすさ
BFF を前に置いた方がいいのは:
- パブリックなブラウザアプリから直接呼ぶ
- secret をブラウザに出したくない
- CORS やドメインの信頼性が問題になる
SOAP を REST にするだけでもかなり前進ですが、それだけでブラウザ配信の問題が全部消えるわけではありません。ブラウザ案件では、「JSON にできるか」だけでなく、「秘密情報をどこまでサーバー側に閉じ込めるか」まで含めて設計した方が安全です。