I.はじめに
1. RPC（リモートプロシージャコール）
ローカルサービス（メソッド）を呼び出すように,,リモートサーバ上の機能を実行し、同じサーバーのサービス（メソッド）を呼び出します。通常の実装では、送信データの形式ことを除いてXML-RPC、実質的に同一のJSON-RPC、通信方式を有する。
（1）利点：
シンプルなデザイン、理解しやすい
軽量ペイロード
高性能
（2）短所：
結合前後端コード高い
コード良好な可読性、関連するコードを容易に配置されていない
機能の多数原因定義され、管理が困難
（3）コア
：RPCはによって次の2点の応答、分散アーキテクチャの中核であり、
同期業務継続クライアントは、サービス側が返す結果またはタイムアウトになるまで待ち、サービス側のメソッドを呼び出し、：呼び出し
非同期呼び出しを：クライアントは、サーバーが自分の業務を継続するために直接戻るのを待つことなく、ミドルウェアにメッセージを送信します。
同期呼び出しWebサービスとRMIの実装があります。サービスWebサービスは、Webベースのコンテナ、根本的な利用異種システム間で異なる言語を求めてhttpプロトコルを提供します。RMIは、実際には、Javaメソッドの戻りオブジェクトと基本データ型、Java言語を構築するのに適した異なるシステム間での通話を可能にするJava言語RPC実装です。
JAVAのリアライズバージョン非同期呼び出しは、JMS（Java Message Serviceの）、ミドルウェアは、ActiveMQのApacheのコミュニティがあり、現在、オープンソースのJMS、カフカメッセージング・ミドルウェア、およびアリRocketMQの別のです。
2. REST（表象状態転送）、プレゼンテーション層の状態遷移
APIの設計において、リソースを検索するパスを使用して、方法は、コンテンツの種類によってリソースを交渉及び型承諾する操作を定義
RESTは、建築様式の基を意味していますインフラの制約と原則。これらのアプリケーションは、制約と原則を満たしているか、デザインがRESTfulなです。RESTのすべてのリソースとしての仕様、およびすべてがネットワーク上のリソースです。
RESTは、新しい技術、コンポーネントやサービスを作成するだけで既存の機能とWebの機能を使用しません。完全にHTTPプロトコルを介して、データ通信は、HTTPプロトコル処理を使用します。アクセスなどのリソース、作成、変更、およびリソースの対応が正確GET、POSTは、HTTPプロトコルのPUTとDELETEメソッドが提供削除するためのRESTアーキテクチャ操作。
それRESTのRepresentational State転送（RESTと呼ばれるのRepresentational State Transferが、）、ソフトウェア・アーキテクチャスタイルです。一般法動詞（GET、PUT、DELETE、POST ）RESTの一意のネットワークリソースを識別するために、HTTP、URIにより定義されたプロトコルは、要求者の様々なニーズに応じて応答は,,そのリソース要求はステートレスで表されます。
（1）利点：
フロントとリアエンド高さが切り離され
た文書を見ていない場合でも、理解しやすいだけでなく、おそらくインタフェースを行うために使用されているものを知っている、
機能インタフェースは団結、拡張が容易で、再利用され、
HTTPのオリジナル機能の使用
（ 2）短所：
時々特に大きなペイロードがなり
、同じページが異なるものを取得するには、APIの番号に電話する必要があり、貧困ネットワークの場合には経験を軽減します
（3）前記
リソース：リソースは、キャリアとしてJSON（または他の表現）、ユーザ指向のデータセットのセットである、概念モデルでの発現データの情報リソースは傾向
いわゆるステートレス、すなわち全：ステートレスを他のリソースが変更されるため、リソースをすることができ、そしてこの位置はURIを経由して他のリソースとは何の関係もありません、それは変更されません。
統一されたインタフェース：RESTfulなアーキテクチャ所定の様式、メタデータ操作、すなわち、CRUD（作成、読み取り、更新、削除、すなわち、削除、変更チェックデータ）運転、それぞれ、HTTPメソッドに対応：リソースを取得するためにGET、POST新しいのためのデータ操作に統一されたインタフェースは、唯一のHTTPメソッドを使用して、あなたはデータの作業を変更するために、すべての追加と削除の調査を完了できるようにリソースを削除するには、DELETE資源（リソースを更新するためにも使用することができます）、リソースを更新するためのPUT、、。
URI：リソースは、URI（ユニフォームリソースロケータ）、特定のリソースへの、すなわち各URIの対応によって指示されてもよいです。このリソースを入手するには、そのURIにアクセスすることができ、URIは、したがって、各アドレスまたは識別子のためのリソースになる
（4）設計原理：
ネットワーク上のすべてのものは資源として抽象化された
リソースごとに一意のリソースを持っています識別子
の形式（XML、JSON、等）の様々な資源を持つ
識別子リソース上の様々な動作は、リソースを変更しない
すべての操作はステートレスであります
通信のない状態では、アプリケーションの状態が要求中リクエスタによって提供されなければならない、特定のリソースに関連付けられた任意のHTTPリクエストを保存せずにサーバー（レスポンダ）を意味します。Web要求のいずれかが他の要求から単離されなければならないと、ネットワーク通信処理に必要な、要求自体に応じて要求端末は、この要求に応じて端末が含まれている要求は、すべての情報が必要な
状態情報がサーバに格納されていることを単に手段そこの状態であり、クライアントに保存された状態情報はステートレスです。Webシステム上に分散、負荷分散を達成するために正確に資するステートレスRESTの原則は、利用可能な複数のサーバが存在し、各サーバは、サーバとタイムリーに送られたクライアント要求を処理することができ、ステートレスを下って行きサーバーが処理できる他への要求、これがすることはできません要求の状態です。
RESTfulなようにRESTfulなAPI（RESTデザインスタイルのAPI）としてRESTスタイルを実現するために設計されたアーキテクチャ、
（5）スタイル
統一インターフェースを作るためにHTTPメソッドを使用して
リターン・ステータス情報にHTTPステータスコードを使用して
3 GraphQL（グラフのクエリ言語）
RPCは、いくつかの一般的な利点およびRESTを学習し、ベースユニットにクエリ、所望のデータへのアクセスを容易にするために、
（1）利点：
低速ネットワーク優れた性能
宣言取得されたデータは、
適切なUIの要件に応じてデータを取得し、回避必要なデータ伝送は、
（2）短所：
定義は比較的複雑である
キャッシュの問題、フィールド・レベルのキャッシュのことを確保するために、より堅牢なメカニズムが必要
バージョンが継続的に更新されるが、それは非常に成熟していないにもある
2つの比較:.
1. RPCサービスプロバイダと電話を界面側に依存しすぎて仕方、コーディングの複雑さにつながり、そして、より軽量なRESTインタフェースはRPCに比べ、サービスプロバイダが、ちょうど紙の契約に頼って、発信者に依存します、コードレベルの強い依存性は存在しません。
単に再利用することが困難敏感2. RPCサービスプラットフォーム：RESTは、クロスプラットフォームであることができ、発信者の任意の言語は、インターフェイス定義に従って実装することができます。
3.ダボRPCサービスコールは、RESTのSpringCloudの採用を使用しています。
4. HTTP通信プロトコルを用いて.REST、RPCは、一般的にTCPに使用される
5性能、低REST、高性能RPC
6柔軟性、可撓性RESTが、低い柔軟性RPCを
遠近法の使用7.は、HTTPインターフェイスは、唯一のサービスプロバイダ（サーバー）に焦点を当てて、呼び出す方法クライアントは、一般的には、いわゆる気にしない、コンテンツが送信される限りとしてクライアントは、HTTPの方法で呼び出しを使用クライアントが使用されているように、あなたは、トランスポート・ネットワーク上の多くの焦点の必要性は、比較は、ビジネスの発展には適用されないことができ、およびRPCサービスのクライアント・インターフェースは、サーバーと一致する必要があります、サーバーは、クライアントによって、方法を提供し、ダイレクトインタフェース通話を開始するために、開発者はより効率的な開発で、ネットワーク伝送の詳細を心配もはや、ビジネスメソッドの呼び出しにビジネスに集中する必要がありません。
8.パフォーマンスの観点から、使用HTTP、HTTPのそれ自体がリッチ状態と拡張機能だけでなく、過度のHttp機能に起因を提供するが、ネットワークにおける情報の伝送をもたらす、パフォーマンスの観点から、より運ぶ必要性を提供より多くの非効率的な、話します。RPCサービスのデータ伝送ネットワーク上の送信のみビジネス関連コンテンツ、データ伝送が小さく、高性能です。
II。該当シーンの
RPCベースのAPIより適切な行動（すなわち、コマンドや手順）、RESTベースのAPIは、CRUDを処理し、（、リソースとエンティティである）モデルを構築するために、より適しています。GET、POST、PUT、DELETE：RESTは、メソッドのようなHTTPを使用して 、OPTIONS あまり一般的に用いられている方法があるPATCH。RPCは、通常はGETメソッドは、通常の情報を取得するために使用され、GETとPOSTメソッドを使用している、POSTメソッドは、すべてのアクションのために使用することができます。
三つの概要
1. RPC：いわゆるリモートプロシージャコール（指向のアプローチ）
SOA：いわゆるサービス指向アーキテクチャ（メッセージ指向）
REST：いわゆるのRepresentational State転送（リソース指向）
2. APIのデザインは、あなたが最初によるAPIの意志の設計を考慮する必要があり、使用する形式を決める人：
オブジェクトがフォーカスや資源プロジェクト、必要バットとエンドユーザーの様々な使用と必要性の容易さにある場合文書を読んで、RESTを使用するのに適している
指向のビヘイビアアクション、またはいくつかの内部のマイクロサービス、高応答の要件は、RPCを考えると
、それはUIに必要な場合は、データ、または弱いネットワーク環境の最適化の必要性を提供し、要求を削減しますGraphQLを考慮することができる
エンドユーザー指向の最高使用RESTfulなHTTP。広範な意識で、直感的に、プログラミング言語は、（デバッグするので、簡単に、シェルを含む）HTTPをサポートする理由は、パフォーマンスは、ユーザーフレンドリーなシェアリンクそれほど重要ではありません。
マシンはずっとあなたも、マシンならば、RESTfulなHTTPを使用することを検討したり、すべての後に、バイナリRPCの多くを使用しようとすることができますされていない場合、内部システムについて、そして、パフォーマンスのギャップは依然として非常に大きいです。
RESTコールと簡単なテストは、RPCは少し面倒ですが、RPC効率が疑いを超えている、RPCの使用は、複数のシステム間で内部的に呼び出すことをお勧めします。サービスは、REST、より適切な、外部に設けられました。
RESTfulなAPIとRPCは、物事の2つの完全に異なる概念である、それらを一緒に置くことができない、とあなたはタリアの比較を主張するならば、私はRESTfulなのRESTfulなAPI RPC、RPCが、同じではないが含まれてRPCの実装だと思いますRESTfulなAPI。
RPC：私は（：彼の選択で、転送データにどのようなネットワークプロトコルなど）することができますが、目的を達成するために使用するものの方法にとして、RPCが前方にアイデアを置くためのリモート呼び出しだと思います。
RESTfulなAPI：アーキテクチャへのRESTスタイルのインターフェースが、それはまた、ネットワークを介して、長距離電話をしたが、リモート呼び出しは、HTTPに限定されています。
