1

我们正在使用 Web-API 开发一个 restservice,并在遵循什么样的路由策略上大吃一惊。

我们得到了一些资源:

  • 成绩
  • 留言
  • 家庭作业

(附带说明:我们计划使用 Hateoas 在资源之间建立链接。)

我们正在考虑 Controller[Action][Id] 导致

API\Grade[?personid] (GET/POST)

API\Grade\{id}[?personid] (GET/PUT/DELETE)

API\Grade\Lastgrades\{days}[?personid] (GET) 

或使用上下文

API\Student\Grade (GET)

API\Student\Grade\{id} (GET)

API\Student\Grade\Lastgrades\{days} (GET)

AND

API\Parent\Student\{id}\Grade (GET)

API\Parent\Student\{id}\Grade\{id} (GET)

API\Parent\Student\{id}\Grade\Lastgrades\{days} (GET)

AND

API\Teacher\Student\{id}\Grade (GET/POST)

API\Teacher\Student\{id}\Grade\{id} (GET/PUT/DELETE)

API\Teacher\Student\{id}\Grade\Lastgrades\{days} (GET)

是否有充分的理由使用一种策略而不是另一种策略?

4

1 回答 1

3

在您的第一个选项中,重点是成绩,这是 API 旨在管理的资源。
在您的第二个选项中,仅通过查看 URL 模式,涉及的资源很少,例如教师和学生。

在不真正了解您的业务用例的情况下,您的问题的答案更多地与您的 API 的初始范围有关。如果它专注于成绩而不是教师或学生,那么您可以只提供 API 来管理“成绩”资源,这意味着您的选项 1。

稍后,如果您还需要管理“教师和学生”,您可以将 options-2 添加到您的实现中。

它们不必相互排斥。

更新 1

角色/上下文不应是 URL 的一部分。它应该像每个角色登录到系统后一样单独处理;应该已经有方法与后端中的角色相关联,例如通过会话等。

URL 设计的重点应该放在资源上,在本例中是成绩。另外,从逻辑上讲,成绩应该与学生相关联,甚至与学生所学的课程相关联,我建议将其设计如下

/api/v1/grades/students/[student-id]/

或者

/api/v1/students/[student-id]/grades/

或者

/api/v1/students/[student-id]/classes/[class-id]/grades/

这些都是可接受的解决方案,根据您的业务用例,一个可能比另一个更好。

这些角色仅在CRUD 操作可以对这些资源起作用时发挥作用,例如教师可以 POST/PUT/GET on

/api/v1/students/[student-id]/grades/

但学生/家长只能做 GET on

/api/v1/students/[student-id]/grades/

您仍然需要考虑将角色/上下文作为整体设计的一部分,并且根据您希望如何支持每个角色将使用 URL 来管理资源的操作,URL 设计可能更有意义。但是“上下文/角色”不应该是 URL 的一部分。

于 2013-10-14T19:51:36.197 回答