0
所以我構建了一個REST API，並且我正在努力處理深層嵌套的關係。下面是一些我所擁有的資源的一個例子：處理嵌套關係的REST API
型材 - 用戶可以是客戶或廠商輪廓。
活動 - 客戶端配置文件可以創建活動
任務（例如，具有屬性，如時間，名稱，位置等社交活動。） - 下一個事件，一個客戶端配置文件將創建一個「任務」這一需求由該事件的供應商簡檔完成（例如，任務可以爲事件提供攝影服務）。
工作要求 - 一旦客戶的個人資料已經創建的任務爲他們的活動，他們可以發出作業請求爲每個任務給供應商的配置文件（這裏的供應商配置文件有機會接受這份工作的要求，成爲HIRED/ASSOCIATED到任務）。
我也使用基於令牌的認證方案。
我的問題：我應該如何去設計的網址？我已經考慮過生成像/tasks/和/profiles/這樣的平坦URL，但是我意識到我的設計是非常層次化的，需要更多的上下文。例如，一個客戶端配置文件可能希望看到他們發出的任務請求，因此URL可能看起來：
/profiles/id/events/id/tasks/id/job-requests/id
我居然不願意維持這種複雜的樹導向網址。哪一個更適合我的場景，爲什麼？
除了選擇平面還是面向樹的URL之外，我還需要爲同一資源提供不同形式的數據。例如，客戶端可能想要訪問其創建的任務，因此應具有該任務的所有屬性，而一旦供應商與任務相關聯（在接受任務請求後），他們只能看到一些屬性的任務。在這種情況下，可以看到需要某種形式的權限級別，因此需要提供更多的上下文？如果是這種情況，我應該如何去提供更多的背景？我已經考慮了兩種選擇：
- 棒與樹爲導向的URL，這將導致這2個網址：
/profiles/id/events/id/tasks/id（客戶端配置文件訪問他們創建的任務，一個事件）/profiles/id/job-requests/id（供應商配置文件訪問客戶端配置的任務，他們有被僱用/相關） - 棒平的URL（
/tasks/id/）兩種客戶端配置文件和供應商配置文件，但是一旦他們提供他們獨特的認證令牌，我可以把它映射到他們的個人資料，並提供必要的和允許數據自動發送給他們。
補充說明：你可能會奇怪，爲什麼我把客戶和供應商的配置文件
/profiles/
這是因爲這兩種輪廓具有非常相似的數據屬性和系統的用戶可能有多個下配置文件（例如，人員A具有客戶端和供應商配置文件並且能夠在它們之間切換）。
謝謝:)