現在、非常に基本的な方法でJPA注釈付きPOJOを公開しているSpringServlet（Jersey製）があります。たとえば、オブジェクトの実際の表現を返すのではなく、Nameなどのフィールドを返して遊んでみました。
もちろん、オブジェクトの実際の表現をリソースとして返したいです...私が立ち往生している部分は、/ foo / {id} /を介してアクセス可能なFoo型のオブジェクトがある場合、それはFooの一部としてのオブジェクトタイプBar-応答でBarをシリアル化したくありません。URIをBarリソースに返したい。
私はここから一人でいますか？その部分を処理するフレームワークはありませんか？特にパスに関して。@Pathで注釈が付けられたBarResourceを作成する必要があるように感じますが、シリアル化中に、定数から読み取られたBarPOJO参照のURIを設定します。タイプを取得してリソース（およびその後@Pathアノテーション）を検索することはできませんが、それは便利ですよね？
リソース、表現、オブジェクトの違いを明確にするまで、混乱したままになる運命にあります。
リソースは、クライアントアプリケーションに役立つ概念または「もの」です。とても曖昧です。これはURIによって識別され、メソッドを使用して操作されます。非常に限られた一連の方法を補うには、曖昧で柔軟である必要があります。
表現は、リソースをある瞬間として表す、ワイヤを介して転送できるバイトのセットです。
オブジェクトは、リソースと直接の相関関係がある場合とない場合がある実装の詳細です。リソースに含まれる情報は、単一のオブジェクトまたはオブジェクトグラフ全体によって実装される場合があります。リソースの内容は、SQLクエリの結果、XSLT変換など、ほとんどすべてのファイルに保存できます。
リソースの表現を作成するためにオブジェクトのシリアル化を使用する場合と使用しない場合があります。オブジェクト間の参照は、単一のリソース内のコンテンツまたはリソース間のリンクに関連している場合があります。ただし、ドメインオブジェクトを表現にシリアル化する場合は十分に注意してください。それはあなたが後悔するために生きるあなたのクライアントとサーバーの間にあるレベルの結合を導入することは確実です。