XML-RPC（エックスエムエル・アールピーシー）は、HTTPを介してXML形式のメッセージでリモートプロシージャコール（RPC）を行うための古典的なプロトコルです。1998年にUserLand Softwareの創業者Dave Winer氏が中心となって設計し、当時としては画期的な「HTTPの上でリモート関数を呼び出す」仕組みを提供しました。後にWiner氏自身が拡張に関与したSOAPの源流となり、現代のWebサービス全般のひな型を作ったプロトコルとしても重要な位置を占めています。WordPressの古い投稿APIやPython標準ライブラリのxmlrpc.clientなど、現在でも実環境で利用されているケースがあり、レガシーシステムとの連携で知識が必要になる場面が残っています。
この記事の目次
- XML-RPCを構成する基本要素
- XML-RPCの典型的な利用フロー
- XML-RPC運用で押さえる注意点
- XML-RPCと後継プロトコルの関係
- まとめ
XML-RPCを構成する基本要素
XML-RPCのリクエストはmethodCallというルート要素を持つXMLドキュメントで、methodName・paramsの2つの子要素で構成されます。methodNameには呼び出したいリモート関数名を、paramsには複数のparam要素を並べ、その内側で型タグ（string・int・double・boolean・dateTime.iso8601・base64・array・struct）を使って値を表現します。数値・文字列・配列・連想配列を共通の方法でシリアライズできることが、XML-RPCの大きな特長でした。
サーバはこれをHTTP POSTで受け取り、対応する関数を実行した結果をmethodResponse要素にラップして返却します。正常時はparams内に1つのparamを返し、エラー時はfaultコードとfaultString／faultCodeを持つfaultレスポンスを返却します。現代の目から見るとペイロードは冗長ですが、当時はHTTPの普及期に「XML＋HTTPで何でも連携できる」という強力なメッセージを業界に与えたプロトコルでした。
XML-RPCの典型的な利用フロー
XML-RPCを用いる場合、クライアントとサーバの間で「どのメソッド名を、どの型の引数で呼び出すか」をあらかじめ仕様書として共有しておくことが前提となります。WSDLのような自動的なインタフェース記述標準は持たないため、APIドキュメントを人間が読んで実装する形式が一般的でした。Python・Java・Perl・PHPなどには標準的なライブラリが用意されており、たとえばPythonならxmlrpc.client.ServerProxyを使うだけで通信処理を完全に隠蔽できます。
実行時の流れは単純で、クライアントは呼び出したいメソッド名とパラメータを与えるだけで、ライブラリが内部的にXML文字列を組み立ててHTTP POSTで送信します。サーバはXMLをパースして関数呼び出しに変換し、戻り値をmethodResponseのXMLとして返却するというサイクルが繰り返されます。WordPressのxmlrpc.phpエンドポイントは、この方式で記事投稿・コメント取得・カテゴリ操作などを長年提供してきました。
XML-RPC運用で押さえる注意点
XML-RPCは仕様上、認証や暗号化を持ちません。認証が必要な場合はBasic認証やトークンをHTTPヘッダで運び、通信路はHTTPSで暗号化するのが基本構成です。また、XMLパーサに対する外部実体注入（XXE）攻撃や巨大ペイロードによるDoSが歴史的に問題となっており、最新のXMLライブラリで外部実体の解決を無効化し、最大要素数やバイト数の上限を必ず設定する必要があります。
WordPressのxmlrpc.phpは過去にブルートフォース攻撃や増幅攻撃の足場として悪用されており、現在はREST APIへの移行が推奨され、未使用環境ではxmlrpc.phpを無効化するのが定石です。Unicode文字を扱う際は、サーバ・クライアントともにUTF-8で統一し、XML宣言の文字エンコーディングを一致させる運用が安全です。新規開発では、後継のJSON-RPC・REST・gRPCといった現代的なプロトコルへの移行を前提に、XML-RPCはレガシー連携用途に限定して扱うのが現実的な指針となります。
XML-RPCと後継プロトコルの関係
XML-RPCとSOAPは血縁関係にあるプロトコルです。Dave Winer氏は1998年にXML-RPCを公開した後、Microsoft・IBMと協力してより拡張性の高い後継仕様としてSOAPの初期版を策定しました。SOAPはXML-RPCのアイデアを下地としつつ、Envelope／Header／Body構造、WSDLによるインタフェース記述、WS-Securityなどの拡張仕様で機能を大幅に強化したものになっています。
その後、XML自体の冗長さを嫌う潮流の中でJSON-RPCが登場し、より軽量なRPCの主役の座は徐々にJSON-RPC・REST・gRPCへと移っていきました。現在のXML-RPCは、新規システムの第一選択肢ではなく、WordPress・Mailman・Drupalなど歴史あるシステムとの連携時に登場する「古典的選択肢」と位置付けられています。ただし、HTTP上でRPCを行うという発想を業界に示した功績は大きく、現代のAPI設計の祖先として理解しておく価値があります。
まとめ
XML-RPCは、HTTPとXMLでリモートプロシージャコールを実現した、現代Webサービスの源流ともいえるプロトコルです。後継のSOAPやJSON-RPCに主役の座を譲りつつも、WordPressをはじめとした歴史あるシステムでは現役で稼働しており、レガシー連携やセキュリティ対策の文脈で理解が求められます。現代のAPI設計を理解するためにも、その仕様と歴史的位置付けを押さえておく価値のあるプロトコルです。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント