RMIとREST APIの違いを気になったからChatGPTに聞いてみた
私はSES企業で働くSE3年目のものです。
現在、某金融機関の２次請けエンジニアとしていわゆるレガシー現場で働いています。
某金融機関のシステムは20年ほど前から作られて、使用されているのはJava Struts2です。
そこで使用されているWebアプリケーションやWebサービス間でデータをやり取りするための手段は「RMI」です。
モダンな言語ではほとんどがREST APIが使われているのでしょうか。
働いた経験がないので、あまり詳しくはわからないのですが、REST APIとRMIの違いについて背景からChatGPTに聞いてみました。
以下引用です。
RMIとREST APIの違い
| RMI | REST API | |
|---|---|---|
| 通信モデル | Javaオブジェクト間のメソッド呼び出し（RPC） | HTTPベースのリソース操作（GET/POST/PUT/DELETE） |
| プロトコル | RMI専用プロトコル（Java RMI） | HTTP（標準的で汎用） |
| データ形式 | Javaオブジェクトの直列化（Serializable） | JSONやXML（言語非依存） |
| 利用できる言語 | Java専用 | 任意（Java, Python, JavaScriptなど） |
| 保守性 | Java依存で密結合になりやすい | HTTP＋JSONで疎結合 |
| デバッグのしやすさ | 専用ツールや知識が必要 | ブラウザやcurlなどでもテスト可能 |
| ファイアウォール越え | 難しい場合が多い（RMIポートなど） | HTTPなので通りやすい |
| 例外処理 | Java例外で制御（RemoteExceptionなど） | HTTPステータスコード（400, 500など）で制御 |
【現場目線の違い】
-
開発者の自由度・拡張性
• RMI：Java以外からアクセスできない。機能追加や改修がJava前提になる。
• REST API：非Java（フロントエンドやPythonなど）からもアクセスできる。将来マイクロサービス化も容易。 -
可搬性と保守性
• RMI：クライアントとサーバーで共有するインターフェース（.classや.jar）が必要。バージョンのずれに弱い。
• REST：URL＋HTTPでインターフェースを定義でき、契約（API仕様）さえ守れば自由度が高い。 -
可視化とAPI管理
• RMI：どんなメソッドがあるか確認するにはコードを見ないといけない。
• REST：OpenAPI（Swagger）などで自動生成・ドキュメント化が可能。
⸻
【なぜRMIが使われているのか？】
• Javaベースで統一されている既存システム。
• 社内LANの閉じたオンプレ環境ならセキュリティ上問題になりにくい。
• Java開発者だけで完結する小規模 or 閉じたシステム。
まとめ
つまり、金融システムのような堅牢なセキュリティが求められるかつ、20-30年前のJavaで作られたシステムではRMIを使用することが多いのではという結論です。
まあ、金融機関のシステムは本当にレガシーですし、スパゲッティ状態のものが多いです。
それは今のVUCAの時代を想定したシステム設計ではなく本当に誰も手をつけたがらない、まさにカオスな状態といえますし、なかなかこのRMIからREST APIにリファクタリングするのは難しい話なのは承知ですが、こうやってモダンな技術とレガシー技術の比較ができるのはレガシーシステムを触っているからこその特権かもしれませんね。
皆さんの何かしらの力添えになれたら幸いです。
AKI