企業の中では、異なる時期に導入されたさまざまなシステムが動いている。それぞれOSやプログラミング言語が異なる他、データ形式や通信方法が違うこともある。システムが増えるほど、個別に連携方法を開発して維持する負担は大きくなる。

　そこで求められたのが、システムの仕様や実行環境の違いを越えて利用できる、標準化された接続方法だった。その答えの一つとして普及したのが、SOAPを使ったWebサービスだ。

　SOAPは、「XML」（Extensible Markup Language）技術を使って構造化された情報をやりとりするためのメッセージングの枠組みだ。特定のOSやプログラミング言語に依存せず、異なる環境で動くシステムを接続できることが期待された。

　SOAPを使ったWebサービスでは、多くの場合、提供する機能や送受信するメッセージ、接続先などを「WSDL」（Web Services Description Language）で記述する。システム同士を場当たり的につなぐのではなく、あらかじめ定義したインタフェースに基づいて連携させる考え方だ。

　企業システムでは、単にデータを送受信できればよいとは限らない。誰が利用できるのか、エラーが起きたらどうするのか、メッセージの安全性や配送の信頼性をどう確保するのかといった要件もある。

　こうした要件に対応するため、SOAPを中心とするWebサービスの周辺には、「WS-Security」（Web Services Security）や「WS-ReliableMessaging」（Web Services Reliable Messaging）をはじめとする関連仕様が整備された。SOAP単体が全てを担ったわけではないが、複数の標準仕様を組み合わせることで、企業システムを厳密なルールに基づいて接続できる点に価値があった。

SOAPが主役から降りた理由

　SOAPを使ったWebサービスは、企業間取引や基幹システムの連携にも利用された。その一方で、SOAPやXML、WSDLなどに加え、必要に応じて周辺仕様も理解しなければならず、開発や運用の負担は大きくなっていった。

　例えば、メッセージが途中で失われた場合にどうするのか、同じ処理が二度実行されることをどう防ぐのか。単純な情報取得では過剰に見える仕組みも、金銭や取引を扱うシステムでは重要な意味を持つ。

　開発ツールによっては、WSDLを基にプログラムを自動生成できたが、製品やツールによる実装の違いが相互接続上の問題を生むこともあった。XMLで記述されたメッセージは記述量が多くなりやすく、通信内容やエラーの調査にも知識が必要だった。

　もちろん、SOAPを中心とする仕組みが理由もなく複雑になったわけではない。複雑な企業要件に正面から応えようとした結果だった。

　その後、Web APIが使われる場所は企業システムの内部だけではなくなった。Webサービスやクラウド、SaaS、スマートフォンの普及により、企業は社内システムだけでなく、さまざまな外部サービスともデータを連携させるようになった。APIを社外の開発者へ公開するサービスも増えていった。

　APIの利用者も、限られた企業システムの開発者から、Webサービスやスマートフォンアプリを作る幅広い開発者へと広がった。そこで重視されるようになったのが、短時間で仕組みを理解し、すぐに利用を試せることだった。

　この変化の中で存在感を高めたのがRESTだ。

Webの仕組みを生かしたREST

　RESTは、SOAPに代わる一つの通信プロトコルではない。Webのアーキテクチャを基に、分散システムを設計するための考え方だ。

　SOAPを使ったWebサービスでは、サービスが提供する処理を定義し、それを呼び出す形がよく採用された。一方、RESTでは、扱うデータや機能を「リソース」として捉え、URI（Uniform Resource Identifier）によって識別する。

　例えば、顧客情報を扱うAPIなら、「顧客番号123」の情報を「/customers/123」のようなURI（Uniform Resource Identifier）で表す。取得にはHTTPの「GET」、作成には「POST」、置換には「PUT」、一部更新には「PATCH」、削除には「DELETE」といったメソッドを使う設計が一般的だ。

　RESTは、Webとは別の場所に新しい連携の仕組みを作るのではなく、URIやHTTPメソッドといったWebの仕組みを生かしてAPIを設計する。この特徴が、クラウドやSaaSをはじめとするWebサービスが広がる時代に合っていた。

　REST APIの普及を後押しした要因の一つに「JSON」（JavaScript Object Notation）がある。

　SOAPで一般的に使われるXMLは、名前空間やスキーマなどを利用して複雑な構造や厳密な定義を表現できる。その一方、JSONは比較的簡潔にデータ構造を記述でき、人が読んだときにも内容を把握しやすい。Web開発で使われるさまざまなプログラミング言語から扱いやすいことも特徴だ。

　RESTとJSONは、必ず組み合わせなければならないものではない。それでも両者の組み合わせは、APIの仕様を理解し、通信を試し、利用を始めるまでの負担を減らした。

　APIを外部へ公開する企業にとっては、機能だけでなく、開発者が利用しやすいこともサービスの競争力になる。RESTとJSONの組み合わせは、APIを企業内の統合技術から、幅広い開発者が利用するサービスの窓口へと広げていった。

SOAPはなぜ現在も残っているのか

　SOAPがWeb APIの主役から降りた理由を「SOAPは複雑で、RESTは簡単だったから」と説明されることがある。だが、それだけでは両者の違いを正確に捉えられない。

　SOAPを中心とする仕組みの複雑さは、厳密なインタフェース定義やメッセージ単位のセキュリティ、信頼性の高い配送など、企業システムの要求に応えた結果でもあった。一方、RESTが広がった時代には、多くの開発者がAPIを素早く理解し、さまざまなサービスを接続できることが重視された。

　RESTがあらゆる面でSOAPより優れていたわけではない。RESTを利用しやすい用途や環境が急速に増え、Web APIの主役に求められる条件が変わったのだ。

　SOAPは現在も、既存の基幹システムや企業間のデータ連携などで利用されている。接続先を含めて安定して動いており、必要な保守体制も確保できているなら、方式が古いという理由だけで直ちに置き換える必要はない。

　特に、連携先の仕様を自社だけでは変更できない場合や、SOAPを中心とする既存の仕組みが業務上必要な要件を満たしている場合は、REST化によって得られる効果より、改修やテストの負担が増える可能性がある。

　一方、SOAPを扱える技術者がいない、利用している製品や実行環境のサポートが終了する、新たなサービスとの接続が難しいといった問題があれば、安定稼働していることだけを理由に維持し続けるのも危険だ。

残すか、切り離すか、置き換えるか

　情シスが確認すべきなのは、SOAPとRESTのどちらが新しいかではない。まず、SOAP連携を支える製品や実行環境のサポート状況、保守できる人材の有無、障害が事業に与える影響、接続先を含む改修範囲を把握する必要がある。

　その上で、新しい接続先や機能追加がどの程度見込まれるか、現在利用しているセキュリティやメッセージ配送の仕組みを移行後にどう実現するか、改修とテストにどれだけの費用や時間がかかるかを検討する。

　選択肢は、SOAPをそのまま残すか、全面的にRESTへ置き換えるかの二択ではない。既存のSOAP連携を維持しながら、その外側に変換用のアダプターやAPIを設け、新しいシステムからは別の方式で利用できるようにする方法もある。

　安定して稼働し、サポートや保守体制を確保できるなら維持する。既存システムへの影響を抑えながら新しい接続先を増やしたいなら、連携部分を切り離す。サポート終了や保守人材の不足によって継続利用のリスクが高まっているなら、置き換えを検討する。技術の世代ではなく、自社が抱えるリスクと得られる効果を比較して判断することが重要だ。

　現在も、全てのシステム連携をRESTだけで解決できるわけではない。利用側が必要なデータを指定できる「GraphQL」、サービス間の効率的なRPC（Remote Procedure Call）に使われる「gRPC」、出来事の発生を非同期に伝えるイベント駆動型の連携など、用途に応じた方法が選ばれている。

　RESTもいずれ別の技術に置き換えられるという意味ではない。APIを利用する人や環境が変われば、重視される条件も変わるということだ。

　SOAPは、異なる企業システムを標準化された方法で厳密につなぐという課題に応えた。その後、APIの利用者と利用環境が広がり、理解しやすさや試しやすさが重視されるようになった。その変化に適していたRESTが、Web APIの主役になったのである。

死神管理人：　結局、SOAPが駄目だったからRESTに負けた、という話ではないんだね。

アンデッド管理人：　そういうこと。SOAPは、企業システムを厳密なルールに基づいてつなぐという、当時の課題に応えた仕組みだった。

死神管理人：　その後、クラウドやスマートフォンが広がって、APIを使う人も使う場所も変わった。だからRESTが選ばれる場面が増えたのか。

アンデッド管理人：　そうだね。ただし、これから何でもRESTにすればよいわけではない。既存のSOAPを維持した方がよい場合もあれば、外側に新しいAPIを設けた方がよい場合もある。

死神管理人：　主役を決めるのは、技術の新しさではない、と。

アンデッド管理人：　そのシステムで何が求められているかだね。SOAPがRESTに負けたというより、Web APIを取り巻く環境が変わり、主役に必要な条件も変わった。情シスに必要なのは、その変化を踏まえて、自社に残る技術をどう扱うか判断することなんだ。