あなたが世界にさらす平らな宇宙を作りなさい。
階層オブジェクトグラフをあらゆる深さまで簡単に処理できるSOAPを使用する場合でも、グラフをフラット化し、すべてを単純なIDにリンクします（データベースIDを使用することもできますが、必要がないという考えです。 PKを世界に公開します）。
アプリ内のオブジェクトユニバースは、必ずしも世界に公開するものと同じではありません。Aに子を持たせ、Bに子を持たせますが、RESTリクエストURLにそれを反映する必要はありません。
なぜ平らにするのですか？そうすれば、後でIDでオブジェクトをフェッチしたり、バーストで送信したりできるからです（どちらも同じ場合、多かれ少なかれ）...そしてそれ以上に、オブジェクト階層が変更されてもリクエストURIは変更されません。 （オブジェクト37252は、再分類された場合でも常に同じです）。
編集：まあ、あなたはそれを求めました...これが私が使用することになったアーキテクチャです：パッケージ：サーバー-フロントエンドサーバーとバックエンドサーバーの間で共有されるスーパークラスが含まれています
パッケージ：frontEndServer-フロントエンドサーバーが準拠する必要のあるサーバーインターフェイスが含まれています。SOAPからストレートWebクライアント（JSONなども使用）に変更する場合は、インターフェイスがすべてレイアウトされているため、インターフェイスは優れています。また、クライアントにトスされるフロントエンドクラスのすべての実装と、クライアントとの通信方法を除く、クラス間の相互作用のすべてのロジックが含まれています。
パッケージ：backEndServer-バックエンドサーバーが準拠するサーバーインターフェイスが含まれています。サーバー実装の例は、MySqlDBと通信するものまたはXMLDBと通信するものですが、サーバーインターフェイスはニュートラルです。このパッケージには、サーバーインターフェイスの実装が作業を実行するために使用するすべてのクラスと、永続性を除くバックエンドのすべてのロジックも含まれています。
次に、これらのそれぞれの実装パッケージがあります...これには、バックエンドで永続化する方法やフロントエンドでクライアントと通信する方法などが含まれます。たとえば、フロントエンド実装パッケージは、ユーザーがログインしたことを認識しているのに対し、frontEndServerは、ユーザーを作成してログインするためのメソッドを実装する必要があることを認識しているだけです。
これを書き始めた後、私はすべてを説明するのにもう少し時間がかかることに気づきました、しかしここにあなたはそれの要点を持っています。