常駐している現場にて、SOAP(※1)で実装されていた通信処理を
REST(※2)に置き換える対応を行ったので、備忘録として、そして同様の対応をこれから
行おうとされている方のために書き残します...
(※1): Simple Object Access Protocol
Webサービス間でXML形式のデータを交換するためのプロトコル（通信規約）
利便性は高いが、処理や構造が複雑で扱いにくいところがある。
(※2): Representational State Transfer
HTTPベースでリクエストに対して、レスポンスをXMLやJSON形式で返す為の基本的な仕組み
SOAPよりも構造が単純で、扱いやすい。
対応前
「基幹システム」は、バッチ処理がメインのサーバー
「中継サーバー」経由で他社ネットワークへの通信が許可されている状態
基幹システム側にはWSDL(※3)という定義体ファイルがあり、
そのファイルを読み込んで、中継サーバーのどのサービスのどのメソッドを呼び出すのかを判断していた。
下記の図であれば、中継サーバーのGetXXXDataServiceメソッドを実行し、
「他シスDB」のデータ取得結果をXML形式で返す。
(※3) : Web Services Description Language（WSDL)
Web上のAPIを呼び出す為の設定記述
この記述がまぁ複雑で、これを読み込んで通信を行う記述もホンマに複雑
REST化
行った対応内容
【基盤システム】
① 基幹システムのWSDLファイルと、SOAPリクエストの記述部分を削除
② 中継サーバーにHTTPリクエスト(POST)を投げる処理を記述
リクエスト内容は下記
http://(中継サーバーのIPアドレス):8080/Controller/GetXXXDataController
【中継サーバー】
基幹システムからのリクエストを受け付け、他シスDBデータを
XMLに編集して返すコントローラ(API)を新規作成
以上の対応を行い、データ取得結果の新旧比較テストを経て、
無事リリースとなりました。
おわりに
SOAP : 定義体(WSDL)に処理内容が事細かに記述されていて、堅牢な通信を実現
REST : 処理が単純になり、カスタマイズも楽に行えるが、SOAPの定義体で賄っていた処理を独自に実装してあげないといけない。