宁静服务的路由策略

Question

我们正在开发一个使用 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)

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

Answer 1

在您的第一个选项中，重点是成绩，这是 API 旨在管理的资源。
在您的第二个选项中，只需查看 URL 模式，就会涉及更多资源，例如教师和学生。

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

稍后如果您还需要管理“教师和学生”，您可以将选项 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 operations 可以对这些资源采取行动时发挥作用，例如教师可以 POST/PUT/GET on

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

但是学生/家长只能做 GET on

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

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