GWTアプリケーションのRESTバックエンドを構築する必要があります
私は新しいアプリケーションを計画しており、可能なフロントエンドとしてGWTを実験しています。私が直面している設計上の質問はこれです。
オプションA：GWT-RPCを使用して、アプリをすばやくビルドする必要があります
オプションB：すべての優れた@ Controller、@ Service、@ Repositoryアノテーションを使用してSpringMVC3.0を使用してRESTバックエンドを構築し、GWTオーバーレイ機能を使用してバックエンドと通信するクライアント側ライブラリを構築します。 GWTリクエストビルダー？
私はこのタイプのデザインに関するすべての賛否両論と人々の経験に興味がありますか？
「GWT以外のフロントエンドでサーバー側のインターフェースを再利用する必要がありますか？」という質問を自問してください。
答えが「いいえ、GWTクライアントがあります」の場合：GWT-RPCを使用して、次の事実を利用できます。サーバー側とクライアント側の両方でJavaオブジェクトを使用できます。これにより、少なくとも<inherits name="com.google.gwt.user.RemoteServiceObfuscateTypeNames" />と一緒に使用すると、通信が少し効率的になり、型名が小さな数値に短縮されます。また、（例外を使用した）より優れたエラー処理、型安全性などの利点も得られます。
答えが "はい、複数の種類のフロントエンドからサービスにアクセスできるようにします"：RESTを使用できます_ JSON（またはXML）を使用します。これは、GWT以外のクライアントでも理解できます。これにより、クライアントの切り替えに加えて、将来、別のサーバー実装（Java以外の場合もある）に簡単に切り替えることができます。欠点は、JSONオブジェクトからNice Javaオブジェクトを構築するために、GWTクライアント側でラッパー（ JavaScriptオーバーレイタイプ ）または変換コードを作成する必要があることです。新しいバージョンのサービスをデプロイするときは特に注意する必要があります。これにより、型安全性の欠如に戻ります。
もちろん、3番目のオプションは両方を構築することです。とにかくパブリックRESTインターフェースがGWT-RPCインターフェースと異なる必要がある場合は、このオプションを選択します。おそらく、使いやすいサービスのサブセットのみを提供します。
RestyGWT プロジェクトも使用する場合は、両方を実行できます。これにより、GWT-RPCを使用するのと同じくらい簡単にRESTベースのJSONリソースを呼び出すことができます。さらに、通常、サーバー側からクライアント側で同じ要求応答DTOを再利用できます。
Spiffy UI Framework を作成したときに、同じ問題が発生しました。 RESTを選択したので、二度と戻ることはありません。GWT-RPCは GWTアンチパターン だとさえ言えます。
RESTエンドポイントを公開するつもりがない場合でも、RESTは良い考えです。REST APIを作成すると、UIが高速になり、APIが改善され、アプリケーション全体がより保守しやすくなります。
RESTバックエンドを構築すると思います。私の最後のプロジェクトでは、最初の数か月間GWT-RPCを使用して開発を開始しましたが、高速なブートストラップが必要でした。後で、REST APIが必要になったとき、リファクタリングを行うのに非常に費用がかかり、2つのバックエンドAPI（RESTとRPC）になってしまいました。
適切なRESTバックエンドを構築し、クライアント側でデシリアライズインフラストラクチャを構築する場合（json\xmlをGWTJavaオブジェクトに変換するため）、RPCの利点はほとんどありません。
RESTアプローチのもう1つの忘れられがちな利点は、クライアントを実行しているブラウザーにとってより自然なことです。RPCは、すべての要求がPOSTを使用するプロピテーションプロトコルです。標準的な方法でリソースを読み取る場合、クライアント側のキャッシュを利用できます。
amsのコメントに答える： RPCプロトコルに関して、前回Firebugを使用して「スニッフィング」したときは、jsonのようには見えなかったので、それについてはわかりません。ただし、jsonベースであっても、サーバーとの通信にはHTTP POSTメソッドのみを使用するため、キャッシュに関するここでのポイントは引き続き有効ですが、ブラウザーはPOST リクエスト。
ふりかえりと何がうまくできたかに関して、リソース指向のアーキテクチャでRPCサービスを作成すると、後でRESTへの移植が容易になる可能性があります。 RESTでは、通常、基本的なCRUD操作でリソースが公開されることに注意してください。RPCサービスを作成するときにそのアプローチに焦点を当てれば、問題はないはずです。
RESTアーキテクチャスタイルは、検査可能なメッセージ（デバッグとセキュリティを支援）、APIの進化、複数のプラットフォーム、シンプルなインターフェイス、障害回復、高いスケーラビリティ、および（オプションで）オンデマンドのコードを介した拡張可能なシステムを促進します。インタラクションごとのパフォーマンスをネットワーク全体の効率と引き換えに、一貫したアプリケーション動作に対するサーバーの制御を低下させます。
「RPCスタイル」（RESTとは反対に）は、プラットフォームの均一性、インターフェイスの可変性、コード生成を促進します（したがって、ネットワークが存在しないふりをする機能がありますが、 誤謬 を参照してください。 ）、およびカスタマイズされた相互作用。ネットワーク全体の効率と、相互作用ごとの高いパフォーマンスを交換します。これにより、一貫したアプリケーションの動作に対するサーバーの制御が向上します。
アプリケーションで前者の品質が必要な場合は、RESTスタイルを使用します。後者が必要な場合は、RPCスタイルを使用します。
サーバー側でHibernate/JPAを使用し、リレーショナルデータを含む結果のPOJOをクライアント（つまり、電話のコレクションを持つEmployeeオブジェクト）に送信することを計画している場合は、必ずREST実装。
1か月前にGWTRPCを使用してGWTプロジェクトを開始しました。 1対多の関係を持つ基になるデータベースからオブジェクトをシリアル化しようとするまでは、すべてうまくいきました。そして恐ろしい：
com.google.gwt.user.client.rpc.SerializationException: Type 'org.hibernate.collection.PersistentList' was not included in the set of types which can be serialized by this SerializationPolicy
これに遭遇し、GWT RPCを使い続けたい場合は、次のようなものを使用する必要があります。
- GWTリクエストファクトリ（www.gwtproject.org/doc/latest/DevGuideRequestFactory.html）-これにより、クライアントと共有するPOJOごとに3つ以上のクラス/インターフェースを作成する必要があります。 痛い！
- ギリアド（sourceforge.net/projects/gilead/）-死んだプロジェクトのように見えます。
現在、 RestyGWT を使用しています。切り替えはかなり簡単で、私のPOJOは問題なくシリアル化されました。
これは、アプリケーション全体の範囲によって異なります。バックエンドを他のクライアントが使用する必要がある場合、拡張可能である必要がある場合などは、RESTを使用して別のモジュールを作成します。バックエンドをこのクライアントのみが使用する場合は、GWT-RPCソリューションを選択してください。