宁静服务的路由策略

Posted 2023-03-31

【中文标题】宁静服务的路由策略

【英文标题】：Routing strategy for a restful service

【发布时间】：2013-10-10 16:40:33

【问题描述】：

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

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

【参考方案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 的一部分。

【讨论】：

嗨，明，我给出的例子是关于成绩的。只有几个角色有等级。学生只能查看他们（自己的）成绩。这些学生的家长也可以查看这些成绩。但是，教师可以对成绩进行 CRUD。在选项 1 中，我让每个角色都指向同一个端点。选项 2 取决于角色上下文。

刚刚更新了答案。本质上，角色/上下文不应该是 URL 设计的一部分。

谢谢，这是有道理的