这个问题是一个非常开放的讨论，它实际上取决于不同的工程师如何解释 REST 标准和最佳实践。尽管如此，作为一名在 REST 服务开发方面有足够经验的软件工程师（并且在专业上遇到了与您相同的问题），我会在这里添加我的输入。
REST 服务开发规则严重依赖于 url 定义。以这样一种方式公开您的 api 非常重要，您的客户只需查看 url 定义就可以准确了解每个 api 发生的情况。
话虽如此，不同的客户（以及不同的工程师）对最佳实践的看法不同。例如，如果您尝试通过电子邮件搜索用户，则至少有两种方法
1) GET /users/emails/{email} // 客户端可以将其解释为
“通过电子邮件获取用户”
2) GET /users?email={email} // 客户端可以将其解释为
由于查询参数，“通过电子邮件搜索用户”
3) GET /users/email={email} // 这可以解释为#1
这取决于开发人员他们希望如何公开此 api 以及他们如何为客户记录它。从不同的角度来看，所有的方法都是正确的。
现在具体回答您的问题。这是我的方法在“User”、“Student”和“Teacher”方面的样子。
我将这 3 个中的每一个都视为单独的资源？为什么？因为它们是单独的类型，即使其中 2 个是从第 3 个扩展而来的。现在我的 apis 会是什么样子？
对于学生：
1) 检索学生列表：GET /students
2) 检索学生 ID：GET /students/{id}
3) 创建学生：POST /students
4) 更新学生：PUT /students/{id}
5) 删除学生：DELETE /students/{id}
6) 搜索学生：GET
/students?{whateverQueryParamsYouWantForSearch}
同样适用于教师。
现在是User。
1) GET /users : 检索所有用户的列表 (Students 和
Teachers)
2) GET /users?type={type} ：这是踢球者。您可以指定
输入学生或老师，您将返回特定的数据
类型（当然有正确记录）
3) POST /users?type={type} : 创建特定类型的用户
（student 或 teacher）
..等等。
主要区别是 .. 具有根 url /users 的 api 可用于两种类型的用户（前提是始终指定类型并记录给客户端）。而Student 和Teacher api 特定于这些类型。
我的钱一直花在特定类型上，而通用类型用于搜索（意味着搜索两种类型的用户..使用/users?params）。这是客户了解正在发生的事情的最简单方法。甚至记录它们也容易得多。
最后谈谈 HATEOAS。是的，这是标准的一部分，最佳做法是始终提供指向您要返回的资源的 url/链接，或者如果您的返回对象很复杂并且包含其他资源，这些资源可能包含本身可能通过 api 公开的资源。例如，
/users?type=student&email=abc@abc.com
将使用该电子邮件返回所有用户，最好在此处关注 HATEOAS 并向每个返回的用户提供一个 URL，使该 URL 看起来像：/students/{id}。这就是我们通常处理 HATEOAS 的方式
这就是我要补充的全部内容。正如我之前所说，这是一个非常开放的讨论。每个工程师对标准的解释都不同，没有一种方法可以处理所有用例。有一些基本规则，如果您遵守它们，客户和其他开发人员会为您鼓掌:)