RPC と REST の違いはなんですか?
リモートプロシージャコール (RPC) と REST は API 設計の 2 つのアーキテクチャスタイルです。API は、2 つのソフトウェアコンポーネントが一連の定義とプロトコルを使用して相互に通信できるようにするメカニズムです。ソフトウェアデベロッパーは、以前に開発したコンポーネントやサードパーティーのコンポーネントを使用して機能を実行するため、すべてを最初から作成する必要はありません。RPC API を使用すると、デベロッパーは外部サーバーのリモート関数を、あたかもソフトウェアのローカルにあるかのように呼び出すことができます。例えば、別のチャットアプリケーションのメッセージング機能をリモートで呼び出すことで、アプリケーションにチャット機能を追加できます。これとは対照的に、REST API では、リモートサーバー上で特定のデータ操作を実行できます。例えば、アプリケーションでは REST API を使用してリモートサーバーに従業員データを挿入または変更することもできます。
RPC と REST にはどのような類似点がありますか?
リモートプロシージャコール (RPC) と REST はどちらも API を設計する方法です。API は現代のウェブデザインやその他の分散システムには不可欠です。これにより、2 つの独立した分散アプリケーションまたはサービスが、他方の動作の内部を知らなくても通信できます。これら 2 つのアプリケーションまたはサービスは、わずかなデータ交換を除いて、互いにほとんど関係がない場合があります。
API は、プログラムのバックエンド (ロジックコンポーネント) がプログラムのフロントエンド (表示コンポーネント) と通信するための一般的なメカニズムでもあります。緊密に連携した統合ではなく API を使用してウェブページや ウェブアプリケーションを設計すると、少ないコードの書き換えでスケーリングや変更が可能になります。
次に、RPC と REST API のその他の類似点について説明します。
抽象化
ネットワーク通信は API の主な目的ですが、下位レベルの通信自体は API デベロッパーから切り離されています。これにより、デベロッパーは技術的な実装よりも機能に集中できます。
通信
REST と RPC はどちらも、基盤となるプロトコルとして HTTP を使用します。RPC と REST で最も一般的なメッセージ形式は JSON と XML です。JSON は可読性と柔軟性があるため好まれています。
言語間の互換性
デベロッパーは、選択した任意の言語で RESTful または RPC API を実装できます。API のネットワーク通信要素が RESTful または RPC インターフェイス標準に準拠している限り、残りのコードは任意のプログラミング言語で記述できます。
アーキテクチャの原理: RPC とREST
リモートプロシージャコール (RPC) では、クライアントはサーバー上でリモート関数 (メソッドまたはプロシージャとも呼ばれます) を呼び出します。通常、呼び出し中に 1 つ以上のデータ値がサーバーに渡されます。
一方、REST クライアントは、特定のサーバーリソースに対してアクションを実行するようにサーバーに要求します。アクションは作成、読み取り、更新、削除 (CRUD) のみに制限され、HTTP 動詞または HTTP メソッドとして伝えられます。
RPC は関数またはアクションに重点を置き、REST はリソースまたはオブジェクトに焦点を当てます。
RPC の原則
次に、RPC システムが通常従ういくつかの原則について説明します。ただし、これらの原則は REST のように標準化されていません。
リモート呼び出し
RPC 呼び出しは、あたかもクライアントのローカルで呼び出されたかのように、クライアントによってリモートサーバー上の関数に対して行われます。
パラメータを渡す
クライアントは通常、ローカル関数とほとんど同じようにパラメータをサーバー関数に送信します。
スタブ
関数スタブはクライアントとサーバーの両方に存在します。クライアント側では、関数呼び出しを行います。サーバーでは、実際の関数を呼び出します。
REST の原則
REST の原則は標準化されています。REST API が RESTful として分類されるには、以下の原則に従う必要があります。
クライアント/サーバー
REST のクライアント/サーバーアーキテクチャは、クライアントとサーバーを分離します。それぞれを独立したシステムとして扱います。
ステートレス
サーバーは、クライアントリクエストの間に、クライアントの状態を記録しません。
キャッシュ可能
クライアントまたは仲介システムは、クライアントが応答をキャッシュするように指定しているかどうかに基づいて、サーバー応答をキャッシュすることができる。
階層型システム
クライアントとサーバーの間に仲介者が存在する可能性があります。クライアントとサーバーはどちらもこれらを認識せず、あたかも直接接続されているかのように動作します。
統一されたインターフェイス
クライアントとサーバーは、標準化された一連の命令とメッセージング形式を使用して REST API と通信します。リソースは URL によって識別され、この URL は REST API エンドポイントと呼ばれます。
仕組み: RPC とREST
リモートプロシージャコール (RPC) では、クライアントは HTTP POST を使用して特定の関数を名前で呼び出します。クライアント側のデベロッパーは、RPC が機能するために関数名とパラメータを事前に知っておく必要があります。
REST では、クライアントとサーバーは GET、POST、PATCH、PUT、DELETE、および OPTIONS などの HTTP 動詞を使用してオプションを実行します。デベロッパーはサーバーリソースの URL を知っていればよく、個々の関数名を気にする必要はありません。
次の表は、クライアントが RPC と REST で同様のアクションを実行するために使用するコードの種類を示しています。
| アクション |
RPC |
REST |
コメント |
| 製品リストへの新製品の追加 |
POST /addProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"} |
POST /products HTTP/1.1 HOST: api.example.com Content-Type: application/json {"name": "T-Shirt", "price": "22.00", "category": "Clothes"} |
RPC は関数に対して POST を使用し、REST は URL に対して POST を使用します。 |
| 商品の詳細情報を取得する |
POST /getProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productID": "123”} |
GET /products/123 HTTP/1.1 HOST: api.example.com |
RPC は関数に対して POST を使用し、パラメータを JSON オブジェクトとして渡します。REST は URL に対して GET を使用し、URL 内のパラメータを渡します。 |
| 商品料金の更新 |
POST /updateProductPrice HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productId": "123", "newPrice": "20.00"} |
PUT /products/123 HTTP/1.1 HOST: api.example.com Content-Type: application/json {"price": "20.00"} |
RPC は関数に対して POST を使用し、パラメータを JSON オブジェクトとして渡します。REST は URL に対して PUT を使用し、パラメータを URL 内および JSON オブジェクトとして渡します。 |
| 製品を削除する |
POST /deleteProduct HTTP/1.1 HOST: api.example.com Content-Type: application/json {"productId": "123""} |
DELETE /products/123 HTTP/1.1 HOST: api.example.com |
RPC は関数に対して POST を使用し、パラメータを JSON オブジェクトとして渡します。REST は URL に対して DELETE を使用し、URL 内のパラメータを渡します。 |
主な相違点: とREST
次に、さらにいくつかの相違点を以下に示します。
開発の時期
RPC は 1970 年代後半から 1980 年代初頭にかけて開発されましたが、REST は 2000 年にコンピューター科学者の Roy Fielding 氏によって最初に作られた用語です。
運用形式
REST API には HTTP メソッドがあるため、サーバー操作のセットは標準化されていますが、RPC API にはありません。一部の RPC 実装は、標準化された操作のためのフレームワークを提供します。
データ受け渡し形式
REST は、任意のデータ形式と、JSON や XML などの複数の形式を同じ API 内で渡すことができます。
ただし、RPC API では、データ形式はサーバーによって選択され、実装中に修正されます。特定の JSON RPC または XML RPC 実装を使用できますが、クライアントには柔軟性がありません。
州/地域
API の文脈では、ステートレスとは、サーバーがクライアントの以前のインタラクションに関する情報を一切保存しないという設計原則を指します。各 API リクエストは個別に処理され、サーバーは保存されているクライアントの状態に依存せずにリクエストを処理します。
REST システムは常にステートレスでなければなりませんが、RPC システムは設計に応じてステートフルでもステートレスでもかまいません。
いつ使うべきか: RPC とREST
リモートプロシージャコール (RPC) は通常、アクション結果を必要とするサーバー上のリモート関数を呼び出すために使用されます。複雑な計算が必要な場合や、プロセスをクライアントから隠した状態でサーバー上でリモートプロシージャをトリガーしたい場合に使用できます。
RPC が適しているアクションは次のとおりです。
- リモートデバイスのカメラで写真を撮る
- サーバー上で機械学習アルゴリズムを使用して不正行為を特定する
- リモートバンキングシステムで、ある口座から別の口座に送金する
- サーバーをリモートで再起動する
REST API は通常、サーバー上のデータオブジェクトに対して作成、読み取り、更新、削除 (CRUD) 操作を実行するために使用されます。そのため、REST API はサーバーのデータとデータ構造を統一的に公開する必要がある場合に適しています。
REST API が良い選択肢となるアクションは次のとおりです。
- 製品をデータベースに追加する
- 音楽プレイリストの内容を取得する
- 個人の住所を更新する
- ブログ投稿を削除する
なぜ REST は RPC に取って代わったのでしょうか?
今日では REST ウェブ API が標準となっていますが、リモートプロシージャコール (RPC) が消えたわけではありません。REST API は、デベロッパーが理解しやすく実装しやすいため、通常はアプリケーションで使用されます。ただし、RPC はまだ存在しており、ユースケースにより適している場合に使用されます。
gRPC などの最新の RPC 実装は、現在ではさらに普及しています。一部のユースケースでは、gRPC のパフォーマンスが RPC や REST よりも優れています。これにより、要求と応答のデータ交換パターンではなく、ストリーミングによるクライアント/サーバー通信が可能になります。
相違点の要約: RPC とREST
| RPC |
REST |
|
| 内容 |
システムにより、リモートクライアントはサーバー上のプロシージャを、あたかもローカルであるかのように呼び出すことができます。 |
クライアントとサーバー間の構造化されたデータ交換を定義する一連のルール。 |
| 以下に使用 |
リモートサーバー上でアクションを実行します。 |
リモートオブジェクトに対する作成、読み取り、更新、削除 (CRUD) 操作。 |
| ベストフィット |
複雑な計算が必要な場合や、サーバー上でリモートプロセスをトリガーする場合。 |
サーバーのデータとデータ構造を統一的に公開する必要がある場合。 |
| ステートフルネス |
ステートレスかステートフルか。 |
ステートレス。 |
| データ受け渡し形式 |
サーバーによって定義され、クライアントで適用される一貫した構造になっています。 |
サーバーによって独立して決定される構造です。同じ API 内で複数の異なる形式を渡すことができます。 |
AWS は API 要件をどのようにサポートできますか?
Amazon Web Services (AWS) には、API 設計者が API ベースの最新のアプリケーションとサービスを構築、実行、管理するのに役立つさまざまなサービスとツールがあります。詳細については、AWS での最新のアプリケーションの構築に関する記事をご覧ください。
API 要件を満たすのに役立つ AWS サービスの例を以下に示します。
- Amazon API Gateway を使用すると、デベロッパーは API を大規模に作成、公開、管理できます。API Gateway を使用すると、コンテナ化されたマイクロサービスアーキテクチャとウェブアプリケーション向けに最適化された REST API を構築できます。
- Elastic Load Balancing (ELB) はネットワークトラフィックを分散してアプリケーションのスケーラビリティを向上させます。マイクロサービス間または gRPC 対応のクライアントとサービス間で gRPC トラフィックをルーティングおよび負荷分散できます。これにより、顧客のクライアントやサービスの基盤となるインフラストラクチャを変更することなく、ソフトウェアアーキテクチャでシームレスな gRPC トラフィック管理が可能になります。
- Amazon Virtual Private Cloud (Amazon VPC) Lattice は、サービス間の通信を一貫して接続、モニタリング、保護するアプリケーションネットワーキングサービスです。コンピューティングリソースとネットワークリソースを自動的にスケールして、高帯域幅の HTTP、HTTPS、gRPC ワークロードをサポートします。
今すぐアカウントを作成して、AWS で REST API とリモートプロシージャコール (RPC) API を使い始めましょう。
