シンプルな Spring MVC RESTful API を開発し、この API へのいくつかのリクエストを実行するためのシンプルな GWT プロジェクトを作成するステージに移動しました。明らかに、JSON メッセージを交換することによって通信が行われることを選択しました。
応答を受信したら、POJO にアンマーシャリングする必要があります。
一般的なアプローチは、いわゆる「オーバーレイ タイプ」を作成することですが、それは私が API で記述した Java クラスの単なる複製に見えます。
問題は、このマーシャリング/アンマーシャリングを実行するための共通クラスを単純に含む共通 API を単純に作成してはいけないということです。
主な利点は、変更が必要な場合にオーバーレイの種類も変更する必要がないことです。
サーバー側のクラス (たとえば、Player) を問題なくシリアル化/逆シリアル化できる場合は、オーバーレイ タイプ/変換なしでクライアント側に送信できます (サーバー上の JSON へのシリアル化 -> トランスポート -> クライアント上の JSON からの逆シリアル化)。 . クライアント側では、たとえば RestyGWT を使用して、自動デシリアライゼーション プロセスをアーカイブできます。オーバーレイ タイプと変換プロセスは、Player インスタンスをシリアル化できない場合 (たとえば、Hibernate によってサポートされている場合) にのみ必要です。
The REST response can be consumed by any client and not specifically one client. If I understand your question correctly, you want to build the logic of marshalling and unmarshalling inside your REST API. Ideally it violates Single Responsibility Principal. You might need to change the mapping logic if the service changes so you are touching two different aspects of an API where as only one component requires change.
Also, the REST API should ideally be designed to be client agnostic. It is your specific requirement to translate them to POJO but another client might want to consume it as simple plain JSON. If you provide an overlay type, your code will be quite loosely coupled.