30

サーバー側でバイナリ データを処理する 5 つのメソッドを作成する必要があります。リモート クライアントはアプレットと JavaScript です。クライアントはファイルをサーバーに送信し、サーバーはこれらのファイルを解析してから、応答を XML/JSON として返す必要があります。

だから私は混乱しています - この場合RESTサービスを使用するのは良い習慣ですか? または、サーブレットを使用する必要がありますか?

私の同僚は私に言った：

「1 つのアプリケーションでのみ使用される REST サービスを作成するのは良くありません。REST は、多くのアプリで使用される場合にのみ作成する必要があります。また、REST には、サーブレットよりもいくつかの欠点があります。REST はサーブレットよりも遅いです。サーブレットよりもスレッドセーフな REST を記述してください」

ただし、サーブレットの使用にはいくつかの欠点があります。呼び出したい関数名を送信する必要があり (つまり、追加の HTTP パラメーターとして関数名を送信します)、doPostメソッド内で次のスイッチを実行します。

switch(functionName) {
 case "function1":
   function1(); 
   break;
 case "function2"
   function2(); 
   break;
//.... more `case` statements....

}

REST の場合、さまざまな機能にさまざまな URL を簡単に使用できます。また、RESTの場合はサーバーからJSON/XMLを返す方が便利です。

4

7 に答える 7

46

ここで 2 つのパラダイムを混同しています。

  • REST はソフトウェア アーキテクチャの「スタイル」です。
  • サーブレットはサーバー側のテクノロジーです。

たとえば、サーブレットを使用して REST のようなサービスを実装できます。

于 2012-09-21T07:11:34.980 に答える
29

1 つのアプリケーションだけで REST を使用するのはよくないという同僚の意見には同意しません。将来、同じ REST API を使用して別のアプリケーションを使用することを決定する可能性があるからです。私があなたなら、純粋な REST を選ぶでしょう。なんで？

  1. 残りの実装に何らかのフレームワークを使用している場合 (たとえば、apache cxfまたはjersey )、箱から出してすぐに多くのものを取得できます。POJO を作成すると、残りが得られ、シリアライゼーションとデシリアライゼーションが得られ、JSON オブジェクトとの間でやり取りされます。すぐに使用できます (最終的には、いくつかの JsonProviders を実装する必要がありますが、これは大したことではありません)。

  2. 直感的に操作できます (残りの API を適切に設計している場合)。

  3. JavaScript クライアントで非常に簡単に使用できます (特に JQuery などを使用している場合)。

ただし、正確に何をしたいかによって大きく異なります。強力なトランザクション ロジックがある場合、残りは非常にトリッキーになる可能性があります。(他の HTTP メソッドを使用せずに) POST 要求のみを実行する場合は、追加のフレームワークや依存関係を作成する必要がないため、サーブレットを使用することをお勧めします。REST は多かれ少なかれアーキテクチャの概念であり、サーブレット テクノロジと矛盾しないことに注意してください。頑固な人であれば、サーブレットのみで REST API を作成できます :-)。私が助けたことを願っています。

于 2012-09-21T07:36:38.733 に答える
4

まず、あなたは 2 つの異なるパラダイムについて話しています。リンゴとオレンジのようなものです。

REST は、HTTP 操作 (GET、PUT など) を使用してリソースの状態を読み書きするサービスのスタイルです。リソースは「名詞」と「物」と考えてください。

一方、サーブレットは、HTTP 要求をカスタム Java コードに接続するために Sun Microsystems によって最初に提供されたソフトウェア仕様です。サーブレットは、多くの場合、「動詞」と「アクション」というメソッド呼び出しの観点から話します。

あなたの質問は、input->output メソッドを処理しようとしていることを暗示しているため、単純なサーブレットだけで仕事をする必要があります。

于 2014-01-19T17:42:03.710 に答える
3

Jerseyの使用とRESTサービスの作成に関する問題は見当たりません。私はRESTタリバンであることを知っていますが、JAX-RSを使用してこの種のアーキテクチャを実装するのは本当に簡単です。

同僚は「RESTは多くのアプリで使用される場合にのみ作成する必要があります」と言っていますが、これがどのように当てはまるのかわかりません。単一のアプリにRESTサービスを作成できないのはなぜですか。

于 2012-09-21T07:31:33.660 に答える
2

あなたの同僚が時期尚早の最適化を適用しているようです。JAX-RS ライブラリですぐに書けるなら、そうしてください。

私の経験では、JAX-RS のパフォーマンス オーバーヘッドは、問題が JAX-RS に適切に対応するサーブレットで直接同等のものを作成する開発および保守のオーバーヘッドを正当化するほど大きくはありません。

于 2012-09-21T08:51:10.643 に答える
1

コンテナのバージョンに応じて、Jersey（またはその他のJAX-RS実装）は引き続きサーブレットを使用して、適切なハンドラにリクエストをディスパッチします。

アプリケーションが本当にRESTfulである場合、JAX-RSは必要な処理を実行します。それ以外の場合は、FrontControllerを使用してリクエストを解釈し、適切なハンドラーに転送することを検討してください。

また、XMLまたはJSONをRESTと混同しないでください。これらは、ほとんどの（すべてではないにしても）JAX-RS実装で無料で入手できますが、これらの実装は、コンテンツマーシャリングを他のライブラリ（JAXBなど）に委任します。

于 2012-09-21T07:25:48.700 に答える
1

類似リンクはこちらです。彼は単純なサーブレット http://software.danielwatrous.com/restful-java-servlet/でそれを行いました

于 2013-08-08T06:14:37.443 に答える