web-dev-qa-db-ja.com

RESTとRPCのWebサービスの違い

JSONパラメーターを受け入れ、メソッド用の特定のURLを持つWebサービスがあります：

http://IP:PORT/API/getAllData?p={JSON}

ステートレスではないため、これは間違いなくRESTではありません。Cookieを考慮に入れ、独自のセッションを持ちます。

RPCですか？ RPCとRESTの違いは何ですか？

web-servicesrestrpc
51
Mazmart

あなたが投稿したものを見ただけでは、RESTまたはRPCを明確に区別することはできません。

RESTの制約の1つは、ステートレスでなければならないことです。セッションがある場合は、サービスをRESTfulに呼び出せない状態があるためです。

URLにアクション（つまり、getAllData）があるという事実は、RPCに対する指標です。 REST表現を交換し、実行する操作はHTTP動詞によって決定されます。また、RESTでは、 コンテンツネゴシエーション は?p={JSON}パラメータ。

サービスがRPCかどうかはわかりませんが、RESTfulではありません。オンラインで違いについて学ぶことができます。始めるための記事があります： RPCとRESTの神話を暴く 。サービスの中身をよく知っているので、その機能をRPCと比較し、独自の結論を導き出します。

36
Bogdan

レストランでの注文をモデル化するHTTP APIの次の例を考えてみましょう。

  • RPC APIは「動詞」の観点から考えて、レストランの機能をパラメーターを受け入れる関数呼び出しとして公開し、これらの関数をHTTP動詞経由で呼び出します最も適切-クエリの「get」など。ただし、動詞の名前は純粋に偶発的なものであり、実際の機能に実際の関係はありません。なぜなら、毎回URL。リターンコードは手動でコーディングされており、サービス契約の一部です。
  • REST APIは、対照的に、問題ドメイン内のさまざまなエンティティをリソースとしてモデル化し、HTTP動詞を使用してこれらのリソースに対するトランザクションを表します-POST作成、PUT更新、およびGET読み取り。これらの動詞はすべて、同じURLで呼び出され、異なる機能：一般的なHTTPリターンコードは、リクエストのステータスを伝えるために使用されます。

注文する：

注文の取得：

注文の更新：

sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpcからの例

55
JerryGoyal

他の人が言ったように、重要な違いはRESTは名詞中心であり、RPCは動詞中心です。これを含めたかっただけです 例の明確な表 ：

 --------------------------- + ----------------- -------------------- + -------------------------- 
 操作                 | RPC（操作）                     | REST（リソース）
 --------------------------- + ----------------- -------------------- + -------------------------- 
サインアップ| POST/signup | POST/persons 
 -------------------- ------- + ------------------------------------- + ---- ---------------------- 
辞任| POST/resign | DELETE/persons/1234 
 --------------------------- + -------------------- ----------------- + -------------------------- 
読むperson | GET/readPerson？personid = 1234 | GET/persons/1234 
 --------------------------- +- ----------------------------------- + -------------- ------------ 
人のアイテムリストを読む| GET/readUsersItemsList？userid = 1234 | GET/persons/1234/items 
 -------- ------------------- + ------------------------------ ------- + -------------------------- 
アイテムを人のリストに追加する| POST/addItemToUsersItemsList | POST /persons/1234/items
--------------------- ------ + ------------------------------------- + ----- ------------------ --- 
アイテムの更新| POST/modifyItem | PUT/items/456 
 --------------------------- + ------------------------------------- + ----------- --------------- 
アイテムの削除| POST/removeItem？itemId = 456 | DELETE/items/456 
 --------------------------- + ---------------------- --------------- + --------------------------

ノート

  • 表が示すように、RESTは特定のリソースを識別するためにURLパスパラメーターを使用する傾向があります
    （例：GET /persons/1234）、RPCは関数入力にクエリパラメータを使用する傾向がある
    （例：GET /readPerson?personid=1234）。
  • 表に示されていないのは、REST APIがフィルタリングを処理する方法であり、通常はクエリパラメータが含まれます（例：GET /persons?height=tall）。
  • また、どちらのシステムでも、作成/更新操作を行う場合、メッセージ本文を介して追加データが渡される方法は示されていません（例：POST /signup または POST /persons、新しい人を説明するデータを含めます）。
  • もちろん、これらのいずれも明確に設定されているわけではありませんが、遭遇する可能性のあるものや、一貫性を保つために独自のAPIを編成する方法についてのアイデアを提供します。 REST URLデザインの詳細については、 この質問 を参照してください。
14
MarredCheese

httpを使用したRPCです。 RESTの正しい実装はRPCとは異なる必要があります。メソッド/関数など、データを処理するロジックを持つことはRPCです。 getAllData（）はインテリジェントなメソッドです。 RESTはインテリジェンスを持つことができません。それは外部インテリジェンスでクエリできるダンプデータである必要があります。

最近の実装のほとんどはRPCですが、多くはXML/SoapではなくHTTP + jsonを使用していることがわかっているため、誤ってRESTと呼んでいます。 RESTはHTTPで救い主であり、SOAPはXMLで悪役です。あなたの混乱は正当化され、あなたは正しい、それはRESTではありません。

HTTPプロトコルはRESTの実装を行いません。 REST（GET、POST、PUT、PATCH、DELETE）とRPC（GET + POST）の両方をHTTP経由で開発できます（例：Visual StudioのWeb APIプロジェクトを使用）。

RPCは古く、すべての学童はRPCが何であるかを知っており、開発されたRESTのほとんどは、当然のことながらRPC（HTTP + Json）になります。しかし、RESTとは何ですか？リチャードソンの成熟度モデルを以下に示します（要約）。レベル3のみがRESTfulです。

  • レベル0：Http POST
  • レベル1：各リソース/エンティティにはURIがあります（ただし、POSTのみ）
  • レベル2：POSTとGETの両方を使用できます
  • レベル3（RESTful）：HATEOAS（ハイパーメディアリンク）または自己探索リンクを使用します

例えばレベル3：

  1. リンクは、このオブジェクトをこの方法で更新し、この方法で追加できることを示しています
  2. リンクは、このオブジェクトは読み取り専用であると述べており、これがその方法です。

人間が使用できるWebサイトを構築しました。しかし、マシンで使用できるWebサイトを構築することもできますか？そこに未来があり、RESTful Webサービスはその方法を示します。

14
Blue Clouds

RESTは、RPCがアクションに関するものであるため、リソースを操作するために最もよく記述されています。

[〜＃〜] rest [〜＃〜]は、Representational State Transferを表します。独立したシステム間の相互作用を整理する簡単な方法です。 RESTfulアプリケーションは通常、HTTPリクエストを使用して、データの投稿（作成および/または更新）、データの読み取り（クエリの作成など）、およびデータの削除を行います。したがって、RESTは、4つのCRUD（作成/読み取り/更新/削除）操作すべてにHTTPを使用できます。

[〜＃〜] rpc [〜＃〜]は、基本的に異なるモジュール間で通信してユーザー要求を処理するために使用されます。例えば仮想マシンの起動時にnova、glance、neutronがどのように連携するかのようなオープンスタック。

7
IRSHAD

私はこう主張します：

私のエンティティはデータを保持/所有していますか？ RPC：ここに私のデータのコピーがあります。私があなたに送ったデータのコピーを操作して、結果のコピーを私に返します。

呼び出されたエンティティはデータを保持/所有していますか？次に、REST：（1）データの一部のコピーを表示するか、（2）データの一部を操作します。

最終的には、アクションのどちらの「サイド」がデータを所有/保持するかです。そして、はい、REST verbiageを使用してRPCベースのシステムと通信できますが、その場合でもRPCアクティビティを実行できます。

例1：DAOを介してリレーショナルデータベースストア（または他の種類のデータストア）と通信しているオブジェクトがあります。私のオブジェクトとAPIとして存在できるデータアクセスオブジェクト間のやりとりにRESTスタイルを使用するのは理にかなっています。エンティティはデータ、リレーショナルデータベース（またはリレーショナルデータストア）.

例2：私は多くの複雑な数学を行う必要があります。オブジェクトにたくさんの数学メソッドをロードしたくありません。あらゆる種類の数学を実行できる他の何かに値を渡し、結果を取得したいだけです。 RPCスタイルは理にかなっています。なぜなら、数学オブジェクト/エンティティがオブジェクト全体に多くの操作を公開するからです。これらのメソッドはすべて個別のAPIとして公開される場合があり、GETを使用してこれらのメソッドを呼び出す場合があることに注意してください。 HTTP GETを介して呼び出しているため、これがRESTfulであると主張することもできますが、実際にはRPCです。私のエンティティはデータを所有/保持しています。リモートエンティティは、送信したデータのコピーに対して操作を実行しています。

3
John Tullis

HTTPを介して、両方ともHttpRequestオブジェクトになり、両方ともHttpResponseオブジェクトが返されることを期待します。その記述でコーディングを続け、他のことを心配することができると思います。

0
acmoune

これは、さまざまなユースケースでそれらを理解して使用する方法です。

例：レストラン管理

RESTのユースケース：注文管理

- create order (POST), update order (PATCH), cancel order (DELETE), retrieve order (GET)
- endpoint: /order?orderId=123

リソース管理の場合、REST is clean。定義済みのアクションを持つ1つのエンドポイント。DB（SqlまたはNoSql）またはクラスインスタンスを世界に公開する方法を見ることができます。

実装例：

class order:
    on_get(self, req, resp): doThis.
    on_patch(self, req, resp): doThat.

フレームワークの例：Python用のFalcon。

RPCのユースケース：運用管理

- prepare ingredients: /operation/clean/kitchen
- cook the order: /operation/cook/123
- serve the order /operation/serve/123

分析、運用、非応答、非代表、アクションベースのジョブの場合、RPCはより適切に機能し、機能的と考えるのは非常に自然です。

実装例：

@route('/operation/cook/<orderId>')
def cook(orderId): doThis.

@route('/operation/serve/<orderId>')
def serve(orderId): doThat.

フレームワークの例：Flask

0
Ali Khosro