したがって、私はREST APIを構築しており、深くネストされた関係を扱うのに苦労しています。 - ユーザーがクライアントまたはベンダープロファイルすることができ入れ子の関係を扱うREST API
プロファイル：ここで私が持っているリソースの一部の例があります。
イベント - クライアントプロファイルは、イベントを作成することができます
タスク（例えば、時間、名前、場所などのような属性を持っている社会的なイベント。） - イベントの下に、クライアント・プロファイルは、「タスク」を作成することが必要そのイベントのベンダープロフィールによって完了される（例えば、タスクはイベントのために写真サービスを提供することができる）。
ジョブ要求 - クライアントプロファイルでイベント用のタスクが作成されると、各タスクのジョブ要求がベンダープロファイルに送信されます（ベンダープロファイルはジョブ要求を受け入れてHired/Associatedタスクへ）。
私はトークンベースの認証方式も使用しています。
私の質問：URLの設計はどうすればよいですか？フラットなURLを作成しようと思っていますが、/tasks/と/profiles/が好きですが、私のデザインは非常に階層的で、より多くの文脈が必要です。
/profiles/id/events/id/tasks/id/job-requests/id
私はこのような複雑なツリー指向のURLを維持するために非常に消極的だ：たとえば、クライアントプロファイルは、彼らがそうURLが見えるかもしれません送り出されたジョブ要求を見たいかもしれません。私のシナリオにはどちらが適しているのですか？
フラットまたはツリー指向のURLを選択する上で、同じリソースに対してさまざまな形式のデータを提供する必要があります。たとえば、クライアントは作成したタスクにアクセスしたいので、そのタスクのすべての属性に対してFULL ACCESSが必要ですが、（ジョブ要求を受け入れた後に）ベンダーがタスクに関連付けられると、タスクのこのシナリオでは、何らかの形式の権限レベルが必要であるため、より多くのコンテキストを提供する必要があることがわかります。この場合、の詳細についてはどうすればいいですか？彼らが持っているクライアントプロファイルのタスクにアクセスする/profiles/id/events/id/tasks/id（クライアントプロファイルは、イベントのために自分の作成したタスクにアクセスする）/profiles/id/job-requests/id（ベンダー・プロファイル：これらの2つのURLにつながるツリー指向のURLを
- スティック：私は2つのオプションを検討しています関連する/雇われて。）
- スティックは、クライアントプロファイルおよびベンダーのプロファイルの両方のためのフラットのURL（
/tasks/id/）に、彼らは彼らのユニークな認証を提供しかし一度トークン、私は自分のプロファイルにマップし、必要に応じて提供することができ、それらに自動的にデータを許可しました。サイドノートとして
：私はこれらのプロファイルの両方が非常に類似したデータ属性を持っており、システムの利用者が複数の場合がありますので、それはです
/profiles/
下クライアントとベンダーのプロファイルを入れて、なぜあなたは不思議に思われるかもしれませんプロファイル（例えば、人物AはクライアントANDベンダープロファイルを持ち、それらを切り替えることができます）。
感謝:)私はフラットな構造を使用することをお勧め