【问题标题】:Hierarchy in REST APIREST API 中的层次结构
【发布时间】:2017-08-09 16:53:23
【问题描述】:

我有这样的层次结构:

Work Experience (like SomeCompany.com)
└─Roles (like Project Manager)
  └─Projects

所以用户可以添加他的Work Experience。为此他可以添加roles 和特定的projects

我想为用户id 1 获取projects,但项目和角色之间只有关系。 我真的需要提出大约 4 个请求才能获得项目吗?

  1. 获取用户
  2. 获得工作经验
  3. 获取角色
  4. 获取项目

因此,如果我有更多不同工作经历的角色,我将不得不提出 20 个请求才能获得我的项目。不是效率不高吗?我将不得不加载一些不必要的数据...

是否可以只创建端点: /projects 并按用户 ID 过滤?

应该如何在 API 上进行管理?对我来说,作为前端开发人员,它看起来效率很低,尤其是当人们主要使用手机时,所以这样的请求会很快耗尽你的电池。

你们如何处理这样的关系?

谢谢!

【问题讨论】:

  • 是什么阻止了您获取用户的所有数据并过滤掉需要在屏幕上显示的内容。如果这对数据大小有挑战并且这是一个特定的端点,您会需要,您可以将其设计为 GET : ://user/{uid}/we/role/project
  • 我在项目的前端工作,我们的后端人员提出了我上面提到的解决方案。你提出的想法在我的世界里是理想的。他们说发行量很大......
  • 如果您认为这很好,您可以将其批准为正确答案.. 谢谢
  • @crotoan “循环”是什么意思?
  • 不确定..我确定上面不是真正的用例..可能是真正的用例有嵌套对象或类似 we->role->project->{we ->role->project->{..}}.. 等等.. 除此之外,这只是有多个循环的问题.. 因为我认为后端开发人员不会抱怨..: )

标签: database rest api hierarchy


【解决方案1】:

是什么阻止您获取用户的所有数据并过滤掉需要在屏幕上显示的内容..

如果这对数据大小有挑战,并且这是您需要的特定端点,您可以将其设计为 GET : <host>:<port>/<context>/user/{uid}/we/role/project

【讨论】:

    【解决方案2】:

    您的 API 实体不应过于紧密耦合。如果你需要得到例如。用户的所有项目,例如,您的projects 表中应该有一个user_id,然后去例如。 /users/<user_id>/projects.

    如果项目是独立且可列出的,/projects 将仅列出 projects(分页等)。

    就个人而言,我倾向于遵循 RESTful API 方法,我发现它真的很有帮助。 This pagethis tutorial 可能会帮助您了解如何更好地组织您的 RESTful API

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2018-12-15
      • 1970-01-01
      • 1970-01-01
      • 2010-10-02
      • 2013-02-21
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多