セキュアなデータ交換におけるSOAP通信のメリット、デメリット
SOAP通信はもう古いのか？
Webアプリケーション間の情報通信において、SOAP通信はもう古い通信手法であるという記述をよく見るようになった。 その理由について調べてみると、概ね以下の様な理由である。
・XMLベースで通信を行う為、データ構造が複雑であり、開発・実装が困難である。通信先とのコミュニケーションの手間も多い ・WSDLを用いた場合のデータ転送量の増加によるパフォーマンスの低下、メンテナンスの複雑さ ・新たに台頭しているREST APIの方が手軽に開発・実装を行えるため、SOAPを選択するメリットが薄い
実際、現状で最もメジャーなGoogle APIも「REST API + OAuth 2.0」での通信を採用していている為、 わざわざSOAP通信を選択するようなケースは今後ますます減っていくと予想される。
WSDLのやり取りにおける失敗
実際、SOAP通信で使用するWSDLはきちんと理解していないと失敗しやすい。 以前、こんな例があった。 フレームワークに「JAVA」と「Apache Axis2」を用いたSOAP通信で商品情報をやり取りしたのだが、登録日時に時分秒が入ってこないという。 その為、同日に登録された商品情報のどれが新しいものか分からない。
調べると、axis2を用いた場合、WSDLからJAVAへデータ変換する際、
WSDLのデータ型：<xs:element minOccurs="0" name="create_date(登録日時のカラム名)" nillable="true" type="xs:date"/> JAVAのデータ型：import java.util.Date; private Date create_date(登録日時のカラム名);
といった変換がされている。 JAVAの方のjava.util.Dateは時分秒を含むため、てっきりこれで問題ないと思いきや、WSDL側の"xs:date"には日付しか含まれず、時分秒が含まれない事が発覚。 テスト中はJAVA側のデータの確認で留まっており、WSDLに変換した後のデータ確認が中途半端だった事が問題の原因。
調べるとWSDLで時分秒を含む形式は"xs:dateTime"。 これでWSDL側を定義し、axis2を用いてコード生成するとJAVA側は「java.util.Calendar(現在はjava.timeパッケージが適用される)」になる。 テストも終了し、データを連携している相手先にもWSDL定義を"xs:dateTime"に変換してくださいと通話で連絡し、 了解ですと返事を貰って進めたところ結合テストでエラー。
「何故……？」と思って調べたところ、"xs:dateTime"の「T」を小文字の「t」で定義していたことが発覚。 その為、「Apache Axis2」でJAVAへ変換をかけた後のデータも当然おかしな定義となり、エラーとなっていた。 笑い話のようだが、こうした些細な変換ミスで何度もテストの時間を取ったので、あまり笑えないことである。 教訓としては、やはり面倒でもデータ連携に関わる改修の場合、 厳密にドキュメントを作って事前に配布しておくことだろう。
それでもSOAP通信を選ぶ理由
このようにSOAP通信に利用するWSDLの形式と通信時のデータ変換については互いの理解が正確でないと思わぬ落とし穴に陥る。 仕様書等を厳密に記述して、開発者・利用者の認識を完全に共通にしなければならない。テスト時、WSDLデータの確認もエビデンス含めてしっかり残す必要がある。 この辺りもSOAP通信が敬遠される理由だろう。 「REST API」であればメジャーなJSONの知識だけでよく、共通の理解も早い。
しかし、それでも何故SOAP通信を選ぶかといえば、専用のセキュア機能が多く、これらの導入が容易な点がある。 SOAPであればHTTPプロトコル以外での通信もできるし、WSDLの暗号化やデジタル署名の付与、Oauth2を含む様々な認証方法の導入もしやすい。 セキュリティ面の担保について問われやすい昨今、SOAP通信でこれらの機能を導入していることが、ユーザへの説得力に繋がりやすいというメリットはある。
単にメジャーだから「REST API」で実装しよう、というだけでは今時分、開発者としては厳しい。「REST API」の場合、セキュリティ要件の担保としてして何ができているか……を常に考えておくことが大事だ。そうすると、通信手段としてSOAP通信やGraphQLを選択する局面も出てくるだろう。
あるいは、自身がデータを受領する側になった時、相手側がSOAP通信を選択している場合もある。 その場合に「何故SOAP通信なのか」という点に着目できるようになっておいた方が好ましい。 ……勿論、定義するWSDLの形式はきちんと文書でやり取りするように心がけておこう。
お知らせ
電巧社ではセキュリティ分野専門のブログも公開しています。ゼロトラストセキュリティを始めとした、ランサムウェアへの対処法等を紹介しています。こちらもよろしくお願いします。