22

これはより理論的な質問です。ここに小さなサーバーを構築しようとしており、そのための API を作成したいと考えています。私は何が良いかを決定しており、SOAP は私の意見では混乱しているため、すでに除外しています。REST と XML-RPC が残っています。私は XML-RPC を本当に楽しんでいます。実装が非常に簡単で、すべてのクライアントが簡単に使用できるほど規則的です。最近では、すべてのクールな子供たちが RESTful な作業を行っており、JSON ペイロードや XML ドキュメント、さらには HTTP POST VARIABLES を使用することもあります。それらの人は、サービスごとに常に車輪を再発明していると思います。XML-RPC を使用する代わりに REST を使用することで、何が得られるかわかりません。

では、XML-RPC を使用するだけでなく、REST+JSON を使用して API を実装する実際的な理由を提供できる人はいますか?

4

2 に答える 2

20

XML-RPC のような REST と RPC の実装は、誤った二分法です。XML-RPC を使用して RESTful インターフェースを実装できます (おそらくそうしたくないでしょうが)。そうは言っても、XML-RPC のような技術を使用して独自の RPC インターフェースを展開するのではなく、通常の HTTP を使用して RESTful な方法でリソースを公開したい理由はたくさんあります。

  1. 将来のアクションは、プロシージャ コールを介してクライアントにハードコーディングされるのではなく、主にサーバーによって制御されるため、展開とバージョン管理が簡素化されます。
  2. キャッシング、スロットリング、バージョン管理などの既存の実装は、すぐに使用できます。
  3. RPC インターフェイスで実行するカスタム プロシージャは、範囲が狭すぎる可能性があります。

詳細については、このブログ投稿を参照してください。

于 2012-12-06T01:06:42.943 に答える
10

  • XML-RPC は特許を取得しています。ある日、その使用に対してロイヤルティを支払うよう求められることがあります。私が知る限り、REST はそうではありません。

  • XML-RPC リクエストは、セキュリティ インフラストラクチャに対して不透明です。一方、HTTP 対応のファイアウォールは、REST 呼び出しによるデータの読み取りは許可するが、更新または削除は許可しないように構成できます。

REST のその他の利点は、大規模なデータ セットの処理に適用されます。

  • REST は通信がはるかに簡単です (特に、XML ではなく JSON を使用する場合)。

  • XML-RPC は HTTP セマンティクスを無視します。すべての XML-RPC 呼び出しは HTTP POST です。これには多くの意味があります。それも含めて

    • REST 要求は、すべての XML-RPC 呼び出しがターゲット サーバーによって処理される必要がある HTTP キャッシュ インフラストラクチャの恩恵を受けます。
    • REST を使用すると、クライアントは単純な HTTP HEAD 要求を使用して更新を確認できます。XML-RPC で同じことを行うには、それを API に組み込む必要があります。

  • XML-RPC クライアントは、応答全体をメモリにロードする必要があります。これにより、REST クライアントが受信したストリームを簡単に処理できる戻り値として提示できるようになります。これは、XML-RPC API が応答のサイズを制限する必要がある場合に、REST 呼び出しが任意の数のレコードで応答することはまったく問題ないことを意味します。

于 2012-11-28T02:48:51.670 に答える