8

動的コンテンツを提供する Web サイトを構築しています。REST を介したサーバー/ブラウザー間のすべての通信。PostgreSQL はデータストアとして使用されます。

私の質問は、任意の GET リクエストに関するものです。その場で html を作成する必要があります (動的コンテンツと共に)。

例として

@GET
@Produces(MediaType.TEXT_HTML)
public String getAllEmployee() {
    // employees fetched from the data base
    String html = "<HTML></head> blah blah";
    return html;
}

私の質問は、html をオンザフライで構築し、ブラウザに送り返す必要があるということです。また、LinkedIn のような大きな Web サイトはどのように機能しますか? 彼らはオンザフライで html ページを生成し、ページを送り返しますか?

私が考えることができる別の方法は、AJAX 要求が埋め込まれたベアボーン html を送信することです。次に、ajax リクエストがサーバーから動的コンテンツを取得します。

4

2 に答える 2

17

REST の主な利点の 1 つは、アクセスされる基盤となるリソースから表現 (エンコード) を分離できることです。

Acceptクライアントがヘッダーを介して設定として HTML を要求した場合、HTML を返すことはまったく問題ありません。クライアントが、JSON や XML など、来年思い浮かぶ超強力なエンコーディングを優先することを示した場合、サーバーは代わりにその形式を返すことができ、URI スキームは 1 ビットも変更されません。

最も重要なことは、REST API を単一のエンコード形式に永遠に結び付けないことです。HTTP コンテンツ ネゴシエーションが API サービス プロバイダーとして提供する素晴らしい柔軟性を利用して、API クライアントがニーズに最も適した形式を選択できるようにします。

于 2012-06-19T18:39:40.543 に答える
4

厳格なルールはありませんが、REST サービスは通常、XML や JSON などの交換形式でデータを返します。その後、クライアント コードは結果を HTML に解釈し、必要に応じてページに挿入します。準備済みの HTML を送信することは望ましくない場合があります。

  1. APIクライアントがデータに対してできることを制限します
  2. サービス層はプレゼンテーション形式を決定する必要がありますが、これは通常望ましくありません
  3. サービスが必要以上のビットを回線上で返す可能性があることを意味します。これは、サイトが混雑している場合に大きな違いを生む可能性があります。

JSON オブジェクトを送り返し、クライアント コードで結果のオブジェクトを何らかのテンプレートに適用して (これを行うには多くの方法があります)、実際の HTML を生成することをお勧めします。

于 2012-05-01T09:57:03.940 に答える