ローカルHTTP呼び出しのオーバーヘッド

Question

私は既存のRESTful APIの周りにwrapperを開発中です。私は基本的にいくつかの前処理を行い、基礎となるAPIを呼び出し、いくつかの前処理をしなければなりません。中には少しキャッシュがあります。このAPIは、http経由のRESTfulアクセス用に特別に設計されています。

私の質問はAPIをリファクタリングする必要がありますので、コードで呼び出すことができます。または、ローカルのhttp呼び出しを行う必要があります。この2番目のオプションは、デカップリングを増やしてくれてうれしいですが、HTTPリクエスト/レスポンスを作成するとパフォーマンスに重大な影響を与える可能性があります。私は、couchDBがそのようなことをしていると聞いたことがあります（そのAPIはRESTfulで、http経由でアクセスされます）。

Answer 1

あなたの現在のRESTful APIがどのように実装されているかに大きく左右されますので、誰もこれに答えることはできません。例えば、ソケットでリッスンしてHTTPリクエストを処理する、比較的短いCプログラムを書くことができます。異なるHTTPメソッドに応答してRESTfulな処理を行う場合は、RESTful APIの実装であり、オーバーヘッドはほとんどありません基底の関数を直接（HTTPなしで）呼び出すだけです。一方、この肥大した重いJava EEモンスターとしてプログラムを書くことができます。その場合、オーバーヘッドがかなり大きくなる可能性があります。

このように、skaffmanは「測定して見る」と言っても間違いない - これは意味のある答えを得るための唯一の方法です。

あなたがこの質問をしている場合は、実際にGoogle規模の問題に直面していないということは間違いないので、リファクタリングが多くの作業になり、HTTPリクエストを傍受するのは簡単ですまず、HTTPラッパーで必要な機能を最初に取得し、パフォーマンスの最適化を心配している作業中の製品があれば、それをお勧めします。

Answer 2

私はそれをリファクタリングします。あなたは、RESTful APIによっていくつかの機能を公開していました。これで、RESTful APIとラッパーによって公開された一連の機能が実現しました。両方を行うことができるようにコードをリファクタリングする必要があります。コードが合理的に整理されているのは簡単です。

Answer 3

疑問がある場合は、作業を少なくする側でエラーが発生します。ラッパーを記述してテストします。あなたがする必要があればリファクタリングしてください。

Answer 4

レイヤードシステムについては、REST Dissertationのセクション5.1.6を参照してください。あなたが実際に説明しているのは、このような階層化されたアーキテクチャの考え方に非常によく合います。効果的には、着信要求をインターセプトし、いくつかの作業を行い、次にそれを次のレイヤーに渡すHTTPプロキシを構築しています。