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

100

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

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

ステートレスではないため、これは明らかにRESTではありません。Cookieが考慮され、独自のセッションがあります。

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

web-services  rest  rpc 
— マズマート
ソース
1
RESTとRPCのどちらが重要なのですか？尋ねる理由は何ですか？
— Bogdan
5
サービスは私のものではなく、RESTであると記載されていますが、そうではないようです。RESTでないことが間違っているかどうかを知りたいと思いました。
— Mazmart 2014年
106
@Bogdanの知識が理由です。
— サー

回答:

68

投稿した内容を見ただけでは、RESTとRPCを明確に区別することはできません。

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

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

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

— ボグダン
ソース
したがって、RESTfulとは、標準に従わないことを選択した場合に、REST以外のすべての標準に従うことを意味します。
— Mazmart 2014年
4
@Mazmart：RESTは一連のガイドラインと制約です。実装できる仕様ではなく、RESTfulサービスがあると主張する場合もそうです。私が気づいたことから、ほとんどの場合、人々はSOAPではないものをREST と呼んでいますが、実際には実際には他の種類のRPCにすぎません。
— Bogdan
122

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

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

注文する：

注文の取得：

注文の更新：

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

— グウラヴ
ソース
33
最後にいくつかのURLの例。
— Fabian Picone
4
私はあなたがURLについて言っていることに同意しません。すべてのRPC呼び出しを同じURLで実行し、RESTを異なるURLで実行することができます。あなたはコインの片面だけを見せています。
— basickarl
ここで説明しているのはRESTではありません-RESTはアーキテクチャパターンです。あなたが説明しているのは、REST over HTTPです。これは、ほとんどの人がRESTについて話すときに考えることです。
— d4nyll
36

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

--------------------------- + ---------------------- --------------- + --------------------------
  操作                  | RPC（操作）                      | REST（リソース）
--------------------------- + ---------------------- --------------- + --------------------------
 サインアップ| POST / signup | POST /人           
--------------------------- + ---------------------- --------------- + --------------------------
 辞任| POST / resign | 削除/ persons / 1234    
--------------------------- + ---------------------- --------------- + --------------------------
 人を読む| 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 | 削除/ 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設計の詳細については、この質問を参照してください。
— マレッドチーズ
ソース
28

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

最近目にした実装のほとんどはRPCですが、多くの場合、誤ってRESTと呼んでいます。HTTPを使用したRESTは救世主であり、XMLを使用したSOAPは悪役です。だからあなたの混乱は正当化され、あなたは正しい、それはRESTではありません。

HTTPプロトコルはRESTの実装を行いません。REST（GET、POST、PUT、PATCH、DELETE）とRPC（GET + POST）は、HTTPを介して（たとえば、Visual StudioのWeb APIプロジェクトを介して）開発できます。

結構ですが、RESTとは何でしょうか。リチャードソン成熟度モデルを以下に示します（要約）。レベル3のみがRESTfulです。

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

例：レベル3（HATEOAS）：

  1. リンクは、このオブジェクトはこの方法で更新でき、この方法で追加できると述べています。

  2. リンクは、このオブジェクトは読み取り専用であり、これが私たちのやり方です。

    明らかに、データを送信するだけではRESTになれませんが、データをクエリする方法についても言及する必要があります。しかし、もう一度、なぜ4つのステップなのでしょうか。なぜステップ4だけでRESTと呼べないのですか？Richardsonは、そこに到達するための段階的なアプローチを提供してくれただけです。

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

PS：RESTは非常に人気があるので、自動テストもそうですが、実世界の例となると……。

— 青い雲
ソース
1
最初の段落では、違いを非常にシンプルで簡単な方法で説明します。+1してください:)
— Nikolas
12

RESTはリソースを操作するために最もよく説明されていますが、RPCはアクションについての詳細です。

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

RPC は基本的に、さまざまなモジュール間で通信してユーザー要求に対応するために使用されます。たとえば、仮想マシンの起動時にnova、glance、およびneutronがどのように連携するかなど、openstackで。

— IRSHAD
ソース
4

私はこのように主張します：

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

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

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

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

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

— ジョン・タリス
ソース
4

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

— Acmoune
ソース
2

ここには良い答えがたくさんあります。私はまだこれを参照しますRPCとRESTの違いを議論する上で非常に良い仕事をしており、私がここで答えのいずれかで読んでいない何かを捉えているので、私は googleブログを。

私が目立ったのと同じリンクからの段落を引用します：

REST自体は、HTTPとワールドワイドウェブを支える設計原則の説明です。しかし、HTTPは商業的に重要な唯一のREST APIであるため、RESTについての説明をほとんど避け、HTTPにのみ焦点を当てることができます。APIのコンテキストでRESTが何を意味するかについて人々は多くの混乱とばらつきを持っているため、この置換は有用ですが、HTTP自体については、より明確で合意が得られます。HTTPモデルはRPCモデルの完全な逆です。RPCモデルでは、アドレス可能な単位はプロシージャであり、問​​題ドメインのエンティティはプロシージャの背後に隠されています。HTTPモデルでは、アドレス可能なユニットはエンティティ自体であり、システムの動作は、エンティティの作成、更新、または削除の副作用としてエンティティの背後に隠されています。

— マトリックス氏
ソース
1

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

例：レストラン管理

RESTの使用例：注文管理

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

リソース管理については、RESTはクリーンです。事前定義されたアクションを持つ1つのエンドポイント。これは、DB（SqlまたはNoSql）またはクラスインスタンスを世界に公開する方法を示しています。

実装例： 

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

フレームワークの例：Falcon for python。

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.

フレームワークの例：Python用Flask

— アリ・コスロ
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.