REST API 处理嵌套关系

Question

所以我正在构建一个 REST api 并且我正在努力处理深层嵌套的关系。这是我拥有的一些资源的示例：

Profiles - 用户可以是 client 或 vendor profile。
事件 - 客户端配置文件可以创建事件（例如，具有时间、姓名、位置等属性的社交事件）
任务 - 在一个事件中，客户配置文件将创建一个 "tasks"，需要由该事件的供应商配置文件完成（例如，一项任务可能是为该事件提供摄影服务一个事件）。
工作请求 - 一旦客户配置文件为其活动创建了任务，他们就可以将每个任务的工作请求发送到供应商配置文件（此处供应商配置文件有机会接受工作请求和成为 HIRED/ASSOCIATED 任务）。

我也在使用基于令牌的身份验证方案。

我的问题：我应该如何设计 URLs？ 我已经考虑过生产平面 URLs 喜欢 /tasks/ /profiles/但我意识到我的设计层次分明，需要更多上下文。例如，客户资料可能希望查看他们发出的工作请求，因此 URL 可能看起来是：

/profiles/id/events/id/tasks/id/job-requests/id

我非常不愿意维护如此复杂的面向树URL。哪一个更适合我的场景，为什么？

除了在面向平面还是面向树的 URLS 之间进行选择之外，我需要为同一资源提供不同形式的数据。例如，客户可能想要访问他们创建的任务，因此应该对该任务的所有属性具有 完全访问权限 而一旦供应商与任务相关联（在接受工作请求之后), 他们只能看到任务的一些属性。在这种情况下，可以看出需要某种形式的权限级别，因此需要提供更多上下文？如果是这种情况，我应该如何提供更多上下文？我考虑过两种选择：

坚持使用面向树的 URLs，这将导致这 2 个 url：/profiles/id/events/id/tasks/id（客户配置文件访问他们为事件创建的任务）/profiles/id/job-requests/id（供应商配置文件访问客户个人资料的任务 hired/associated.)
坚持为客户资料和供应商资料使用平面网址 (/tasks/id/)，但是一旦他们提供了他们唯一的 身份验证令牌 ，我就可以将其映射到他们的配置文件并自动向他们提供必要和允许的数据。

附带说明：您可能想知道为什么我将客户和供应商资料放在

下

/profiles/

这是因为这两个配置文件具有非常相似的数据属性，并且系统的用户可能有多个配置文件（例如，A 具有客户和供应商配置文件，并且能够在它们之间切换）。

谢谢:)

Answer 1

结构

我建议使用平面结构：

/tasks/
/profiles/
/events/

因为可以显示与不同配置文件相关的事件以及与不同事件相关的任务。从前端的角度来看，/events?profile_id=<id> 和 /profile/<id>/events/ 之间的区别非常小。应在模型级别和文档中描述应用程序的嵌套结构。

权限

此问题与 API 端点结构无关。假设用户想要到达事件。无论端点结构如何 - 您需要检查用户是否可以访问此事件。因此，您有 event 个实例，并且可以在必要时检查用户对模型字段 profile 的访问权限。

Answer 2

我正在使用 Django 嵌套路由器 (https://github.com/alanjds/drf-nested-routers) 来处理嵌套关系。

REST API 处理嵌套关系

REST API dealing with nested relationships

rest

nested

relationship

django-rest-framework