XML-RPC vs REST
これはより理論的な質問です。ここに小さなサーバーを構築しようとしています。そのためのAPIを作成したいと思います。私の意見では、それは混乱しているので、私は何がより良いかを決定しており、すでにSOAPを除外しています。 RESTとXML-RPCが残っています。私はXML-RPCを本当に楽しんでいます。実装は非常に簡単で、すべてのクライアントが簡単に使用できるほど定期的です。最近、すべてのクールな子供たちは、JSONペイロードやXMLドキュメント、さらにはHTTP POST VARIABLESを使用して、RESTfulな作業を行っています。私はそれらの人が常に各サービスの車輪を再発明すると思います。 XML-RPCを使用するよりもRESTを使用することで何が得られるかわかりません。
それで、ここの誰かが、XML-RPCを使用するだけでなく、REST + JSONを使用してAPIを実装する実際的な理由を提供できますか？
XML-RPCのようなRESTとRPCの実装は、誤った二分法です。 XML-RPCを使用してRESTfulインターフェースを実装できます（おそらくそうしたくないでしょうが）。とはいえ、XML-RPCなどのテクノロジーを使用して独自のRPCインターフェイスをローリングするのではなく、VanillaHTTPを使用してRESTfulな方法でリソースを公開したい理由はたくさんあります。
- 将来のアクションは、プロシージャ呼び出しを介してクライアントにハードコーディングされるのではなく、主にサーバーによって制御されるため、展開とバージョン管理が簡素化されます。
- キャッシュ、スロットリング、バージョン管理などの既存の実装は、そのまま使用できます。
- RPCインターフェイスを使用してロールするカスタムプロシージャは、範囲が狭すぎる可能性があります。
詳細については、 this ブログ投稿を参照してください。
XML-RPCは特許に抵触します。ある日、その使用料を支払うように求められることがあります。私の知る限り、RESTはそうではありません。
XML-RPC要求は、セキュリティインフラストラクチャに対して不透明です。一方、HTTP対応ファイアウォールは、REST呼び出しでデータを読み取ることはできるが、データを更新または削除することはできないように構成できます。
RESTのその他の利点は、大規模なデータセットの処理により多く適用されます。
RESTはネットワーク上ではるかに軽量です（特にXMLではなくJSONを使用する場合）。
XML-RPCはHTTPセマンティクスを無視します。すべてのXML-RPC呼び出しはHTTPPOSTです。これには多くの意味があります。それを含む
- RESTリクエストは、すべてのXML-RPC呼び出しをターゲットサーバーで処理する必要があるHTTPキャッシュインフラストラクチャの恩恵を受けます。
- RESTを使用すると、クライアントは単純なHTTP HEADリクエストを使用して更新を確認できます。XML-RPCで同じことを行うには、APIに組み込む必要があります。
XML-RPCクライアントは、応答全体をメモリにロードして、RESTクライアントがストリームの到着時に処理するのが簡単な場合に、戻り値として表示できるようにする必要があります。これは、 XML-RPCAPIが応答のサイズを制限する必要がある任意の数のレコードで応答するREST呼び出しに対してはまったく問題ありません。