モバイル開発のためのRESTとRPC

多くの人が知っているように、最近のモバイル開発は急増しており、私がコーディングしているものに影響を与えていると思います。具体的には、モバイルアプリケーション向けのWebサービスの開発に興味があります。

RPCとRESTの2つのアーキテクチャが考えられます。私はRESTサービスとRPCサービスの両方を開発しましたが、RPCサービスは、特にPHPなどの言語でコーディングする方がはるかに簡単であることがわかりました。それに関する問題はスケーラビリティにあるようです-多くの手順が存在する場合、サーバー側は簡単に混乱する可能性があります。

一方、RESTははるかに構造化されているように見え、サーバー側での保守が比較的容易になりますが、データを複数のリソースに分割する可能性があり、モバイルアプリケーションには（複数の理由で）悪影響を及ぼします。

私が経験したことから、ほとんどの場合RPCは少し良いようです：

• クライアント側とサーバー側の両方が、使用可能な手順と実行される呼び出しの数を最小限に抑えることを懸念しています。
• アーキテクチャのルールに従うことは、そうでなければ可能である最適化で対抗しません。

RESTやRPCについて誰かに説明してもらうことはあまり期待していません。Webはそれでいっぱいです。モバイルアプリの開発経験のある人に、サーバーサイドでこれら2つのアーキテクチャを使用することについての意見を表明してほしい。ヒントも歓迎します（だれがヒントを好きではないですか？）。

RPCはRESTよりもバイナリプロトコルになりがちですが、必ずしもそうである必要はありません。また、RPCは呼び出しごとに単一のプロシージャポイントとして実装される傾向がありますが、そうである必要はありません。RESTスタイルの動詞を最初の引数として取る単一のRPCプロシージャを実装できます。RPCはセミ/ステートフルアプローチを使用する場合がありますが、呼び出しごとに「Cookie」を渡す場合は、必ずしもそうである必要はありません。

今日ではすべてが開発サポートにかかっており、Webベースの言語用のREST APIが増えているため、人々はRESTを使用しています。よりユーザー中心の開発ビューを使用している場合は、おそらくRPCメカニズムの方が適しているでしょう。柔軟性を利用してより圧縮されたバイナリプロトコルを提供し、それを好きなように実装します-単一の手順これは、IDまたは「動詞」に基づいてルーチンにルーティングされ、IDを渡すことで完全なステートレスになります。これらはすべて、非常にRESTのように見えるように実装できますが、オーバーヘッドは大幅に低くなります。

いくつかのRPCシステムがあります。モバイルアプリ用のプロトコルバッファーまたはスリフトを試してください。

APIの再設計に関するNetflixの記事をご覧になることをお勧めします。http： //techblog.netflix.com/2012/07/embracing-differences-inside-netflix.html

TL; DR：

• RESTは一般的におしゃべりなAPIを引き起こします。操作が複数のリソースを操作する必要がある場合は、複数の呼び出しが必要になります（つまり、低速です）。
• 1つのAPIがさまざまなコンシューマーにうまくマッピングされないため、Netflixがクライアントコードの一部をサーバーに移行しています。各コンシューマーは、サーバーに独自のアダプター/オーケストレーションレイヤーを提供して、さまざまなコンシューマーへのAPIアクセスを最適化できます。

個人的なメモ：

• RPCを古いスタイルのSOAP / CORBA / RMIエンタープライズ肥大化プロトコルに関連付けないでください。たとえば、JSON-RPCは、RPCを実行するための非常にシンプルでエレガント、かつ機敏なプロトコルです。
• RESTはCRUD APIに最適です。ただし、APIが非常にアクション指向である場合、これをREST動詞/エンドポイントにマッピングするのが面倒なことがあります。