46

REST APIの構築に取り組んでいます。私の質問は、Jersey を使用する場合、サービスの構築と Response オブジェクトの返還、または Bean またはコレクションの返還の違いは何ですか。私は成功した呼び出しのみに関心があり、エラーや例外的な状況に対して適切な例外をスローしています。

次に例を示します。

@Produces(MediaType.APPLICATION_JSON)
public Response search(FooBean foo){
    List<FooBean> results = bar.search(foo);
    return Response.ok(results).build();
}

対。

@Produces(MediaType.APPLICATION_JSON)
public List<FooBean> search(FooBean foo){
    List<FooBean> results = bar.search(foo);
    return results;
}

両方の例が使用されているのを見てきましたが、サービス メソッドを認識しやすくするために、2 番目のシナリオをお勧めします。これらの両方の方法に対する応答を調べたところ、同じように見えます。

考え？

4

3 に答える 3

41

相違点は、JAX-RS 仕様で説明されています。

3.3.3 戻り型

リソース メソッドは、void、Response、GenericEntity、または別の Java 型を返す場合があります。これらの戻り値の型は、次のように応答エンティティ本体にマップされます。

void
結果は、ステータス コード 204 の空のエンティティ本体になります。

応答
は、応答のステータス プロパティによって指定されたステータス コードを使用して、応答のエンティティ プロパティからマップされたエンティティ ボディになります。null の戻り値は、204 ステータス コードになります。Response の status プロパティが設定されていない場合: null 以外のエンティティ プロパティには 200 ステータス コードが使用され、エンティティ プロパティが null の場合は 204 ステータス コードが使用されます。

GenericEntity GenericEntity
の Entity プロパティからマップされたエンティティ本体になります。戻り値が null でない場合は 200 ステータス コードが使用され、null 戻り値は 204 ステータス コードになります。

他の
返されたインスタンスのクラスからマップされたエンティティ本体になります。戻り値が null でない場合は 200 ステータス コードが使用され、null 戻り値は 204 ステータス コードになります。

応答とともに追加のメタデータを提供する必要があるメソッドは、 Response のインスタンスを返す必要があります。 ResponseBuilder クラスは、ビルダー パターンを使用して Response インスタンスを作成する便利な方法を提供します。

「通常の」Bean は、追加のメタデータ (応答ヘッダー、特殊なステータス、特殊なコンテンツ タイプなど) を設定できることをResponse除いて、ほとんど同じ方法でマップされます。Responseどちらを使用するかは、完全にあなた次第Responseです。柔軟性が向上しますが、通常の Bean はより「自己文書化」されています。

于 2013-05-03T05:18:16.120 に答える
4

私の個人的な意見ですが、応答に DTO (Bean/Bean のコレクション) が含まれている場合、残りのサービスは常に DTOを返す必要がありますが、 Response オブジェクトは返さない必要があります。

動機: 早いか遅いかにかかわらず、残りのクライアント apiを提供することで、クライアントが残りのサービスを簡単に使用できるようにするよう求められます。通常、残りのインターフェイスを抽出し、残りのサービスでそれらを実装する必要があります。これらの残りのインターフェイスは、残りのクライアントのクライアントによって使用されます。

クライアントの観点から見ると、DTO の処理とプレーンな応答には大きな違いがあります。Response が使用される場合、クライアントは次のように強制されます。

  1. 応答コードを明示的にチェックして、正常な応答を処理します
  2. コードを明示的にチェックしてエラーを処理する
  3. 自分で応答の本文を DTO に変換します。

つまり、Response の処理は、メソッドでエラー コードを返すのと非常によく似ており、非常に悪い習慣と見なされています。エラーを 1 か所で処理するために、例外が使用されます (エラーを処理する FP の方法について話しているのではなく、これが最適です)。

それで、あなたは何をすることができますか：

  1. リクエストが正常に処理された場合は、残りのサービス データを DTO/Bean に変換して返します。
  2. 検証が失敗した場合、または何か問題が発生した場合は、残りのサービスで例外をスローします。おそらく、デフォルトの例外マッパーは適切ではないため、独自の例外マッパーを実装する必要があります。

したがって、事前に考える場合は、DTO を返す必要があります。

たとえば、ファイルをエクスポートするときなど、プレーンな応答を返す必要がある場合のユースケース。JAX RS は InputStream オブジェクトを返すことを許可していないようです。わかりません、確認する必要があります。

もう 1 つの使用例は、@Perception によって指摘されましたが、ルールというよりも例外です。

応答とともに追加のメタデータを提供する必要があるメソッドは、Response のインスタンスを返す必要があります。ResponseBuilder クラスは、ビルダー パターンを使用して Response インスタンスを作成する便利な方法を提供します。

注: これは JAX RS の一般的な質問であり、Resteasy や Jersey などの正確な実装には依存しません。

于 2017-05-29T08:00:43.640 に答える