Loading article…
XML-RPCは、呼び出しをエンコードするためにXMLを使用し、トランスポートメカニズムとしてHTTPを使用するリモートプロシージャコール（RPC）プロトコルです。 [1]
歴史
XML-RPCプロトコルは、 UserLand SoftwareとMicrosoftのDave Winerによって1998年に作成されました。[2] Microsoftは、このプロトコルをB2B電子商取引の取り組みを拡大するための不可欠な部分と見なしていました。[3]新しい機能が導入されるにつれて、この標準は現在のSOAPに進化しました。[4]
UserLandは、 1998年6月にリリースされたFrontierウェブコンテンツ管理システムのバージョン5.1からXML-RPCをサポートしました。[4] [5]
XML-RPC の、人間が読み書きでき、スクリプト解析可能な HTTP ベースのリクエストとレスポンスの標準というアイデアは、Allaire のWeb Distributed Data Exchange (WDDX) や webMethod のWeb Interface Definition Language (WIDL) などの競合仕様にも実装されています。[6] COM、CORBA、Java RMIオブジェクトを XML 構文でラップし、HTTP 経由で転送する先行技術は、DataChannel の WebBroker テクノロジにも存在していました。[7] [8]
リモートプロシージャコール（RPC）におけるXMLの一般的な使用は、1998年3月に提出された暫定出願の利益を主張して、2006年4月にフィリップ・メリック、スチュワート・アレン、ジョセフ・ラップによって特許取得されました。この特許は、バージニア州フェアファックスに所在するwebMethodsに譲渡されました。この特許は2019年3月23日に失効しました。[9]
使用法
XML-RPC では、クライアントは、XML-RPC を実装するサーバーに HTTP 要求を送信して、HTTP 応答を受信することで RPC を実行します。呼び出しには、複数のパラメーターと 1 つの結果を含めることができます。プロトコルでは、パラメーターと結果のいくつかのデータ型が定義されています。これらのデータ型の一部は複雑で、ネストされています。たとえば、5 つの整数の配列であるパラメーターを持つことができます。
パラメータ/結果構造とデータ型のセットは、一般的なプログラミング言語で使用されるものを反映することを目的としています。
承認目的でのクライアントの識別は、一般的な HTTP セキュリティ メソッドを使用して実現できます。識別と認証には、基本アクセス認証を使用できます。
リソース表現(ドキュメント) が転送されるRESTful プロトコルと比較すると、XML-RPC はメソッドを呼び出すように設計されています。実際的な違いは、XML-RPC の方がはるかに構造化されているため、共通のライブラリ コードを使用してクライアントとサーバーを実装でき、特定のアプリケーション プロトコルの設計とドキュメント化の作業が少なくなることです。[引用が必要]一般的な RESTful プロトコルと XML-RPC の顕著な技術的違いの 1 つは、多くの RESTful プロトコルがパラメーター情報に HTTP URI を使用するのに対し、XML-RPC では URI はサーバーを識別するだけであることです。
JSON-RPC はXML-RPC に似ています。
データ型
一般的なデータ型は、以下に示す例の値を使用して XML の同等のものに変換されます。
例
典型的な XML-RPC リクエストの例は次のようになります。
<?xml version="1.0"?>
<methodCall>
<methodName> examples.getStateName </methodName> <params> <param> <value><i4> 40 </i4></value> </param> </params> </methodCall>
典型的な XML-RPC 応答の例は次のようになります。
<?xml version="1.0 " ?> <methodResponse>
<params> <param> <value><string>サウスダコタ</string></value> </param> </params> </methodResponse>
典型的な XML-RPC 障害は次のようになります。
<?xml version="1.0"?>
<methodResponse>
<fault> <value> <struct> <member> <name> faultCode </name> <value><int> 4 </int></value> </member> <member> <name> faultString </name> <value><string>パラメータが多すぎます。 </string></value> </member> </struct> </value> </fault> </methodResponse>
批判
XML-RPC の最近の批評家 (2010 年以降) は、RPC 呼び出しはプレーン XML で実行でき、XML-RPC は XML に何の価値も追加しないと主張しています。XML-RPC と XML はどちらも、XML スキーマで定義されているフィールド名や XML-RPC のパラメータ名など、アプリケーション レベルのデータ モデルを必要とします。さらに、XML-RPC は同じオブジェクトをエンコードするためにプレーン XML と比較して約 4 倍のバイト数を使用し、それ自体がJSONと比較して冗長です。[10] [11] [12]
参照
参考文献
- ^ Simon St. Laurent、Joe Johnston、Edd Dumbill。(2001 年 6 月) 『XML-RPC による Web サービスのプログラミング』 O'Reilly。初版。
- ^ Box, Don (2001 年 4 月 1 日)。「SOAP の簡潔な歴史」。O'Reilly。2010年10月 27 日閲覧。
- ^ Rupley, Sebastian (1999年6月30日). 「XMLの次のステップ」. PC Magazine . 2000年3月4日時点のオリジナルよりアーカイブ。2015年11月17日閲覧。
- ^ ab Walsh, Jeff (1999年7月10日). 「Microsoft spearheads protocol push」. Infoworld . 1999年9月14日時点のオリジナルよりアーカイブ。2015年11月17日閲覧。
- ^ Walsh, Jeff (1998年6月29日). 「UserLandがFrontier 5.1をリリース、フリーウェアモデルを廃止」InfoWorld。 1999年9月15日時点のオリジナルよりアーカイブ。2015年11月17日閲覧。
- ^ Udell, Jon (1999 年 6 月 7 日). 「XML-RPC の調査: DCOM? CORBA? RMI? なぜ XML-RPC だけではだめなのか?」. Byte . 2000 年 3 月 4 日時点のオリジナルよりアーカイブ。2015年11 月 17 日閲覧。
- ^ Walsh, Jeff (1998 年 5 月 25 日). 「W3C が DataChannel の WebBroker を承認」. Infoworld . 第 20 巻、第 21 号. 1999 年 9 月 10 日時点のオリジナルよりアーカイブ。2015 年11 月 17 日閲覧。
- ^ Vizard, Michael; Walsh, Jeff (1998 年 6 月 29 日). 「DataChannel の Dave Pool が、さまざまなニーズに合わせて XML の役割を形成することについて語る」. Infoworld . 1999 年 9 月 16 日時点のオリジナルよりアーカイブ。2015年12 月 8 日閲覧。
- ^ Merrick; et al. (2006年4月11日). 「米国特許7,028,312」。2011年12月3日時点のオリジナルよりアーカイブ。 2008年9月18日閲覧。
- ^ 「プレーン XML と比べて XML-RPC の利点は何ですか?」Stack Overflow。2009年 9 月 9 日。2011 年4 月 7 日に閲覧。
- ^ 「XmlRpc と代替案のメリットに関する公開投票」 intertwingly.net。2006 年 11 月 22 日。2011年4 月 7 日閲覧。
- ^ Jon Canady (2010 年 1 月 14 日). 「REST があるのに、なぜ XML-RPC なのか?」. joncanady.com. 2013 年 5 月 11 日時点のオリジナルよりアーカイブ。2011 年4 月 7 日閲覧。
外部リンク
- 公式サイト