XML-RPCをまっすぐなHTMLフォームで使用する利点は誰にも分かりますか？ 一見すると、彼らは同じことを達成するようです。 XML-RPCはXMLを使用して "フォーマット"されていますが、フォーム内で同じことができます（テキストボックスと考える）。XML-RPCとHTMLフォーム
クライアントPCで実行されるスクリプトからデータを取得するアプリがあります。スクリプトからの出力はXMLです。現在、フォームPOSTを使用してアプリケーション（CodeIgniterを使用してPHP）に送信されます。私はXML-RPCを使って調べるように言われましたが、 "なぜ"なのかを理解しようとしています...
XML-RPCの主な利点は、リモートプロセスが通信するためのグルーコードを書く必要がないことです。多くの言語で利用可能なさまざまなXML-RPCクライアントライブラリがあります。豊富なAPIを持っている場合、XML-RPCはリモートプロセスをそのAPIに簡単に接続できる方法です。プレーンなwww-form-encoded POSTで同じタスクを実行するには、APIをフォームに変換し、要求をapi呼び出しにディスパッチする必要があります。これを支援するシステムはいくつかありますが、XML-RPCを介してAPIを公開するよりも難しいことは確実です。
一方、プレーンフォームのエンコードされたリクエストで豊かなAPIを公開している場合、クライアントとサーバーの両方を別のインターフェイスに移植する作業を正当化するのは難しいです。
HTML形式はXML-RPCと匹敵しません。
HTMLフォームを使用してWebページで入力データを取得し、XML-RPCを使用してXMLを使用してリモートプロシージャを実行します。
通常、UIを使用せずに一部のプロシージャをリモートで実行しようとすると、XML-RPCを使用します。
データをwww-form-encoded（または "query string style"）とvs POST-XML-RPCでエンコードすることは、実際には味の問題です。 XMLをすべてのものに使う方が好きな人もいます。
私の意見では、XML-RPCは少し日付が付けられています。別のプロトコルについて話している場合を除き、これはSOAPを先行させたものです。私はまったくそれを使用しません。代わりに、SOAPベースのサービス、またはRESTベースのサービスを使用します。
なぜですか？なぜSOAPまたはRESTベース、XML-RPCを使用するのですか？それが古かったからといって、それが「悪い」という意味ではありません... –
私は同意しません。とりわけ、古いものはツールの数が少なく、それを知っている人が少なく、バグが修正される可能性が低いなどです。さらに、SOAPに置き換えられた理由もあります。理由がなければ、SOAPはありません。 –
私はフォームページを必ずしも必要としません。私は、POST入力を受け入れ、XMLを処理し、それに作用するページを持つことができます。私が見ることのできる、実際の（実用的な）違いはXML_RPCです。 –
私は知っています。しかし、HTMLフォームと言っても、後でSCRIPT（あなたが参照しているPOST入力を受け入れるページ）に投稿されたページ（POST）のフォーム
を参照していることに注意してください。だからこそ私はあなたがいろいろなことを話していると思った。 –