Question

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

个人资料 - 用户可以是客户端或供应商个人资料。
事件 - 客户端配置文件可以创建事件（例如，具有时间，名称，位置等属性的社交活动）任务 - 在某个事件下，客户端配置文件将创建需要由THAT事件的供应商配置文件完成的“任务”（例如，任务可能为事件提供摄影服务）。
作业请求 - 一旦客户端配置文件为其事件创建了任务，他们就可以将每个任务的作业请求发送给供应商配置文件（此处供应商配置文件有机会接受作业请求并变为 HIRED / ASSOCIATED 到任务）。

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

我的问题：我应该如何设计网址？我已经考虑过制作像/tasks/和/profiles/这样的平面网址，但我意识到我的设计是非常分层的需要更多背景。例如，客户端配置文件可能希望查看他们发出的作业请求，因此URL可能显示为：

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

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

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

坚持使用面向树的URL，这将导致这两个URL：/profiles/id/events/id/tasks/id（客户端配置文件访问他们为事件创建的任务）/profiles/id/job-requests/id（供应商配置文件访问客户端配置文件的任务，他们一直在的雇用/相关联即可。）
坚持客户档案和供应商档案的平面网址（/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处理嵌套关系

2 个答案: