タグ付けされた質問 「rpc」

RESTful Webサービスを実装していますが、利用可能なアクションの1つはになりますreload。設定、キャッシュなどを再ロードするために使用されます。 GETこのような単純なURIから始めました${path}/cache/reload（パラメーターは渡されず、URIのみが呼び出されます）。GETリクエストでデータを変更しないでください。 RESTful Webサービスでアクション/コマンドを呼び出すために使用する正しい動詞はどれですか？ リロードは、独自のキャッシュ/構成/などをリロードするREST Webサービスのコマンドです。クライアントに情報を返すメソッドではありません。 おそらく私がやろうとしていることはRESTではありませんが、それでもこの方法で行う必要があるものです。このreloadメソッドは、アプリケーションの範囲内で意味のある実際の例に過ぎず、ほとんどの回答はそれに焦点を当てていますが、実際には、CRUDを実行しないがデータ/データを変更するアクションをトリガーする動詞を知る必要がありました状態。 Stack Overflowでこの詳細な回答を見つけました。件名：https ://stackoverflow.com/questions/16877968/

80 rest  rpc 

Steve VinoskiによるREST、Reuse、Serendipityに関するこの講演を見た後、（XML-）RPC-ishセットアップのグリーンフィールドプロジェクトにRESTがより良い方法で解決できなかったビジネスケースがあるのではないかと思います。 彼が言及したいくつかのRPC問題： 言語に焦点を当てる（分散システムをその言語に適合させ、その逆ではない） 「ローカルに見えるようにする」（およびルールではなく例外として障害と遅延に対処する） 言語に依存しないことを意図しているが、依然として主要な成分として言語間で「関数呼び出し」を持っている IDLボイラープレート 型の安全性の錯覚 そして、さらにいくつか... 少しドラマ化するために、RPC vs RESTのGoogleインスタント結果をいくつか示します。

33 web-services  rest  use-case  rpc 

私はごく最近、少なくとも私が知っている典型的なWebアプリケーションフレームワークと比較して、Webアプリケーションにかなり珍しいカスタムフレームワークを使用している会社で働き始めました。RESTful Webサービスの代わりに、RPCメカニズムを使用してサーバーと通信します。 サーバーとの通信は単純な関数呼び出しのように見えますが、関数はクライアントではなくサーバー上で実行されます。サーバー側には、クライアントが呼び出すことができる機能を定義する方法があります。これをhttpリクエストに変換する方法の詳細は完全に抽象化されています。 私は今これを短い時間だけ使用しましたが、それはかなり便利なようです。しかし、私はこのアプローチのどのような欠点が欠けているのか疑問に思っています。他の誰もが違うやり方をしているように見えますが、これは通常、前者に比べてはるかに高い確率で、私が愚かで素晴らしいことをしているかもしれないというサインです。

18 web-applications  rest  rpc 

私と友達の間で議論を解決してください。 現在、製品APIを設計しています。製品エンティティは次のようになります { "Id": "", "ProductName": "", "StockQuantity": 0 } 製品の販売はサードパーティが処理し、StockQuantityフィールドを減らすことができるように購入数量を通知する義務があります。 私のアプローチ： PUT /api/Product/{Id}/ --data { "StockQuantity": "{NewStockQuantity}" } サードパーティは、製品のクエリ、現在のStockQuantity購入数量に基づく計算、およびPUT新しい値でのリクエストの送信を担当します。 私の友人はサードパーティに計算を望まない。彼のアプローチ PUT /api/Product/{Id}/DecreaseStock --data { "PurchasedQuantity": "{PurchasedQuantity}" } したがって、計算を行って、 StockQuantity 私は関数ベースのエンドポイントを作成したくありません、そして彼は計算を行うためにサードパーティを信頼したくありません。 この問題に取り組むための正しい方法は何でしょうか？

8 design  design-patterns  rest  api-design  rpc 

多くの人が知っているように、最近のモバイル開発は急増しており、私がコーディングしているものに影響を与えていると思います。具体的には、モバイルアプリケーション向けのWebサービスの開発に興味があります。 RPCとRESTの2つのアーキテクチャが考えられます。私はRESTサービスとRPCサービスの両方を開発しましたが、RPCサービスは、特にPHPなどの言語でコーディングする方がはるかに簡単であることがわかりました。それに関する問題はスケーラビリティにあるようです-多くの手順が存在する場合、サーバー側は簡単に混乱する可能性があります。 一方、RESTははるかに構造化されているように見え、サーバー側での保守が比較的容易になりますが、データを複数のリソースに分割する可能性があり、モバイルアプリケーションには（複数の理由で）悪影響を及ぼします。 私が経験したことから、ほとんどの場合RPCは少し良いようです： クライアント側とサーバー側の両方が、使用可能な手順と実行される呼び出しの数を最小限に抑えることを懸念しています。 アーキテクチャのルールに従うことは、そうでなければ可能である最適化で対抗しません。 RESTやRPCについて誰かに説明してもらうことはあまり期待していません。Webはそれでいっぱいです。モバイルアプリの開発経験のある人に、サーバーサイドでこれら2つのアーキテクチャを使用することについての意見を表明してほしい。ヒントも歓迎します（だれがヒントを好きではないですか？）。

8 rest  mobile  server-side  rpc