REST WebサービスとRPCのようなWebサービスの違いは何ですか？
AJAXを使用してサーバーからJSONデータを取得するWebアプリケーションがあります。Cookieを設定できるように、ユーザーは最初にブラウザーでログインする必要があります。GETおよびPOST動詞が使用されます。ここで、GETはデータの取得用であり、POSTはデータを変更するすべての操作用です。
私の理解では、RESTは、ユーザー認証情報がeveryリクエストとPUTおよびDELETE動詞も使用されます。
私の質問は、エンドポイントがユーザーのブラウザのみを目的としている場合、REST WebサービスはRPCのような方法に比べてどのような利点がありますか？RESTは、クライアントが不明な場合に役立ちますが、jQuery ajax呼び出しのみを使用している場合、RPCのような方法よりもメリットはありますか？
RESTとRPCの大きな違いの1つは、RESTはすべてリソースに関するものであり、RPCはアクションに関するものです。たとえば、真にRESTfulなサービスの場合 http://domain.com/service/User/jason/add または http://domain.com/service/User/addUser?username=jason）のようなものを呼び出すことは決してありません。 。RESTfulサービスでは、URL内のリソースのみを参照し、HTTP動詞とリクエストの本文を使用してそのリソースをどう処理するかを定義します。したがって、http：/domain.com/service/へのGETリクエストjasonは、リソース（jasonユーザー）に関する情報を返す必要があります。より具体的に言って http://domain.com/service/user/jason と言うこともできますが、結果は同じであるはずです。 jasonという名前のユーザーを追加する場合は、まったく同じURLを使用します http://domain.com/service/user/jason ただし、PUT動詞を使用すると、リクエストの本文に追加のデータが含まれます。 。jasonリソースを削除するには、ここでもまったく同じURLを使用します（ h ttp：//domain.com/service/user/jason ）そしてDELETE動詞を使用します。更新するには、POST動詞を使用します。
RESTは、他の開発者が使用する予定の公開APIに最適です。それらは非常に標準的なものにすることができるので、使用するサービスに関する既存の知識を大量に必要としません。 WSDL呼び出しなどはありません。ステートレスであるため、部分的なネットワーク障害時にWSDLをより安定させることもできます。
あなたが説明していることから、私はあなたが本当にRESTfulなサービスを必要とするとは思わない。ただし、より標準的なAPIが必要になる場合は、今後検討することをお勧めします。内部使用のみに使用するプロジェクト用にRESTサービスを作成しましたが、これは、場合によっては他の数十のサービスから、将来的には他の開発者。最初はいくつかのプロジェクトにしか使用していませんでしたが、最終的な目標には、より標準的なインターフェイスが必要でした。
このように考えてください-重要なのは機能ですか、それとも作用している情報ですか？
RESTを扱っているときは、情報の状態を処理していることになります。現在の情報が何であるかを確認するか（GET）、特定のドキュメントを変更するか（POST、DELETE）、新しいドキュメントを作成します。 （PUT）。
RPCでは、プロシージャ/関数/メソッド/操作...言語で呼び出すものは何でもです。情報は、サービスで操作されたり、サービスから返されたりするものにすぎません...しかし、それは多くの情報の1つである可能性があります。アイテムのリストを検索して返している可能性があります。または、相互作用が必要な場所で何かを交渉している可能性があります。 （RESTのネゴシエーションの大部分はHTTPを介して処理されるため、AcceptおよびAccept-Languageヘッダーを使用して処理する必要があります）しかし、より重要なのは操作です。
次に、3番目のタイプがあります。これはdocument/literal SOAP ...ここで重要なのはメッセージであり、呼び出されている関数がメッセージに基づいて何であるかを推測する必要があります。 CRUD操作を処理するだけで、これはおそらく問題ありません。RESTこの場合の利点は、WSDLを引き続き使用できることです。したがって、送信する必要のある要素を事前に知っています。そしてその見返りに何を期待するか。
それらはすべて機能します...それは主に、問題についてどのように考えるか、そしてAPIとして公開する必要があるものから変換するのがいかに簡単かということです。ゼロから始める場合は、おそらく何でもできます。私は個人的にSOAP（document/litまたはRPC））が好きで、誰かがbootstrapクライアントに使用できるWSDLファイルを提供できます。私は人々が数時間以内に深刻なクエリを実行する場合がありました（空の文字列とnullの送信の違いなど、APIの抽象的な微妙な点のいくつかを説明するには時間がかかりましたが、私は同じでしたREST付きの問題）
RESTはリソースを操作するために最もよく説明されていますが、RPCはアクションに関するものです。
REST：はRepresentational StateTransferの略です。これは、独立したシステム間の相互作用を整理する簡単な方法です。 RESTfulアプリケーションは、HTTPリクエストを使用して、データの投稿（作成および/または更新）、データの読み取り（クエリの作成など）、およびデータの削除を行います。したがって、RESTは、4つのCRUD（作成/読み取り/更新/削除）操作すべてにHTTPを使用します。
RPC： RPCは基本的に、ユーザーの要求を処理するためにさまざまなモジュール間で通信するために使用されます。例えば仮想マシンを起動するときにnova、glance、neutronがどのように連携するかのようなopenstackで。
REST/RPC：
プログラミングアプローチとして、RESTはWebサービスとRPCの軽量な代替手段です。Webサービスと同様に、RESTサービスは次のとおりです。
- プラットフォームに依存しない（サーバーがUnixであるか、クライアントがMacであるか、その他であるかは関係ありません）、
- 言語に依存しない（C＃はJavaなどと通信できます）、
- 標準ベース（HTTP上で実行）、および
- ファイアウォールが存在する場合でも簡単に使用できます。
あなた方全員にそれを壊すことを嫌います。 RPCは、基盤となるリモート動作を抽象化する市内通話を行っています。そして何を推測しますか？ RESTを実行することは同じことです。RESTについての引数はリソースが正しくないため、実際には直接アクションを呼び出します。
私はREST jsonsを使用したHTTP経由はRPCの形式であると主張します。
他の一般的なRPCには、たとえばSOAP
REST呼び出し元オブジェクトとの結合が少ないことについては正しいです-SOAPからWSDLファイルを呼び出す必要があるWebサービスと比較している場合）サーバー、はいよりも、REST Webサービスはあまり結合されていません（つまり、呼び出す前にWebサービスの知識は必要ありません）。ほとんどの場合、トークンは要求とともに渡される必要があります。与えられた「表現」。
REST from ajaxを使用しても、大きなメリットはないと思います。実際、処理しているAPIによっては、URIパラメーターとして渡されるトークンが必要になる場合があります（ querystringパラメーター）SOAPベースのWebサービスを使用している場合、これは必要ありません。実際には、SOAP Webサービスをajax呼び出しと組み合わせるのは、非常に簡単です。データをJSON形式でデータ化し、JSONをサーバー側のオブジェクトに逆シリアル化します。さらに、jQueryを使用すると、これらすべてが非常に簡単になります。