私は、Webサービスを介して(Java)バックエンドと通信するリッチインターネットWebアプリケーションを開発中です。Flex/FlashとGWT/Javascriptの両方でユーザーインターフェイスのプロトタイプを作成しましたが、これらのRIAプラットフォームはRPCスタイルのバックエンド通信方式(Flexの場合はAMF、GWTの場合はGWT-RPC)を好む傾向があることに気付きました。
私の場合、サーバーは、私が作成していない他のクライアントにもWebサービスを提供する必要があります。このため、私は標準ベースのWebサービス(SOAPやRESTなど)に傾倒しています。RIAは、他の人に提供しているのと同じWebサービスを使用する必要があると確信しています。私が経験から精通しているRPCスタイルをモデル化しているため、SOAPを「取得」します。私はRESTを初めて使用しますが、CXF/Jacksonを使用してRESTバックエンドのプロトタイプを作成しました。ただし、現時点では、REST APIは依然としてRPCスタイルのAPIのように感じられます。これは、HATEOASのアイデアに頭を悩ませているためだと思います。
Roy T. Fieldingsの役立つブログ投稿を約10回読んだことがあり、光が見え始めていると思います。たとえば、リソースとともにさまざまな状態遷移へのリンクを含めると、クライアントとサーバー間の結合の量を実際に減らすことができることは明らかです。私のクライアントは、その時点で表示されているエンティティで実行できる法的操作へのアクセスをユーザーに提供するボタンをレンダリングするだけで済みます。
しかし、RIAとそのサーバーアプリケーション間の緩い結合は重要ですか?
その性質上、RIAはサーバーデータモデルと非常に緊密に結合されています。箱から出して、彼らは多くのことを前提としています。緩い結合は設計目標ではないため、RPCスタイルのアプリケーションプロトコルも好むのはそのためだと思います。しかし、HATEOASを真剣に受け止めれば、実行可能なデータモデルと操作についてほとんど想定しない、はるかに一般的なRIAクライアントを作成できることに気づき始めています。これにより、バックエンドの変更を通じてクライアントを維持するための労力を減らすことができますが、これは理にかなっていますか?メリットはコストを上回りますか?
ps-2つの詳細-このアプリケーションには、非常に複雑で、深くネストされたデータモデルがあります。また、100%純粋なREST Webアプリではないと誰かが言っても、私はそれほど気にすることはできませんでした。