私は、Webサービスを介して（Java）バックエンドと通信するリッチインターネットWebアプリケーションを開発中です。私は、Flex/FlashとGWT/Javascriptの両方でユーザーインターフェイスのプロトタイプを作成し、これらのRIAプラットフォームがRPCスタイルのバックエンド通信（Flex向けAMFとGWT用GWT-RPC）を好む傾向があることに気付きました。GWTリッチインターネットアプリケーション（RIA）とREST HATEOAS - どのように互換性がありますか？
私の場合、サーバーは、私が作成していない他のクライアントも提供する必要があります。このため、私は標準ベースのWebサービス（SOAPやRESTなど）に傾いています。私は、RIAが他の人に提供するのと同じWebサービスを使用しなければならないと確信しています。私は経験から慣れているRPCスタイルをモデリングするので、SOAPを "取得"します。私はRESTを初めて使っていますが、CXF/Jacksonを使用してRESTバックエンドのプロトタイプを作成しました。しかし、現時点では、私のREST APIはまだでRPCスタイルのAPIのようにと感じています。私はHATEOASの考え方に頭を悩ませているからです。
私はRoy T. Fieldings helpful blog postを約10回読みました。私は光を見始めていると思います。たとえば、私のリソースと一緒にさまざまな状態遷移へのリンクを含めると、私はクライアントとサーバーの結合量を本当に減らすことができます。クライアントは、その時点で表示されているエンティティで実行可能な法的操作へのアクセス権をユーザーに提供するボタンをレンダリングするだけで済みます。
しかし、RIAとそのサーバーアプリケーションの間の疎結合は重要ですか？
本質的に、RIAはサーバーデータモデルと密接に結びついています。箱から出て、彼らは多くのことを前提としています。私はそれがRPCスタイルのアプリケーションプロトコルを好んでいる理由を推測しています。なぜなら、疎結合は設計目標ではないからです。しかし、私たちがHATEOASを真剣に取り上げると、実行できるデータモデルと操作についての仮定をほとんど作らない、より一般的なRIAクライアントを書くことができるようになりました。これにより、バックエンドの変更によってクライアントを維持する努力の量を減らすことができます。これは意味がありますか？利益はコストを上回っていますか？
p.s. - 2つの詳細 - このアプリケーションには、非常に複雑で深くネストされたデータモデルがあります。また、私たちが100％純粋なREST Webアプリケーションではないことを誰かが教えても、私は気にすることができませんでした。
私はこれらの種類のハイパージェネリックアプリを以前から何度も見てきました。どちらも本当に本当のプログラミング言語だったのですか、実際に何かを実際に行うように構成するのは恐ろしいほど困難でした。または両方。 –
今日、他の誰かが私に語ったように、ブラウザ内にRIAブラウザを構築しているようです（赤い旗！）。ドメイン固有の言語についてのあなたのコメントは、私が自分自身で考えていることが多いため、神経を襲った（第2の赤旗）が、それは私たちの目的ではないことを思い出させた。あなたの答えは、私の考えを結晶化させる助けになりました。私はアジャイルなアプローチに戻って、即時のニーズに応えるシステムを構築します。実際にはクライアント/サーバーの結合を減らすために、HATEOASから多くのものを引き出します。 – HDave
私はDSLが好きですが、自分が行っていることに非常に特化していることを確認します。 –