REST - 用户和用户配置文件（1:1 关系）路由和端点结构答案

【问题标题】：REST - User and User Profile (1:1 relation) routes and endpoints structureREST - 用户和用户配置文件（1:1 关系）路由和端点结构
【发布时间】：2022-09-27 17:01:47
【问题描述】：

我目前正在开发一个 REST api（使用 mongoDb、node.js 和 express）来处理 4 种用户。我决定使用一个集合来存储所有类型的用户（电子邮件、哈希、角色等）之间的公共数据，并使用 4 个集合来存储相应用户类型的配置文件数据。用户配置文件和用户之间将是一对一的关系。另外，请记住，用户将在其他集合中被引用（主要用于用户配置文件数据）。我想知道构建路由和端点的最佳方法是什么。我应该为每种用户类型（比如说/students、/proffessors 等等）设置一个单独的路由，还是只有一个端点（/users）来处理所有与用户相关的请求。例如，如果我想做与用户配置文件相关的请求（GET、PATCH 等），我应该使用/users/{userId}/profile 还是/students/{studentId}。对于像 /users/{userId}/profile/proffessors 这样的请求，我猜第二个选项 (/students/{studentId}/professors) 可以更好地避免超长的 URI（因为 userId 可能会变得很长）。

最后一个与此数据模型相关的问题：就像我说的，我将引用其他集合中的用户来获取用户配置文件数据。我应该参考用户还是只参考用户个人资料，以避免加入 3 个集合？

请记住，我对网络开发很陌生，并且正在努力学习。非常感谢：）

标签： mongodb api rest express data-modeling

【解决方案1】：

两者都可以，REST 不关心路径结构。 URI 标准只写了路径应该包含 URI 的分层部分，而查询应该包含非分层部分。

至于资源，它们不应该来自数据库结构。您需要考虑要支持的操作，并将操作名称转换为 HTTP 方法和 Web 资源。类似readUserProfile(userId) 到GET /users/{userId}/profile。通常使用 REST，您可以将超链接发送给 Web 服务使用者，例如

{
    metadata: {
        operation: {
            name: "readUserProfile",
            parameters: ["userId"]
        },
        httpMethod: "GET", 
        uriTemplate: "/users/{userId}/profile",
        parameters: {
            userId: {
                type: "UserId",
                required: true
            }
        }
    },
    data: {
        type: "readUserProfile",
        parameters: {
            userId: 123
        }
    }
}

您可以将元数据分离到文档 JSON 文件中并仅发送数据：

{
    type: "readUserProfile",
    parameters: {
        userId: 123
    }
}

而服务消费者代码可以做到

service = new REST.WebService("https://example.com/api/docs.json");
profileData = await service.readUserProfile(123);

或者

service = new REST.WebService("https://example.com/api/docs.json");
userData = await service.findUser({userId: 123});
link = response.findLink({type: service.readUserProfile});
profileData = await link.follow();

这就是为什么只要遵循 URI 和 URI 模板标准和 REST 约束，消费者就不应该太在意 URI 结构。除非您违反 HATEOAS 约束，否则长度根本不重要。但即使在这种情况下，您的文档也必须包含 URI 模板，因此对于服务使用者开发人员来说，它只是复制粘贴。如果您愿意，您甚至可以同时支持这两种 URI 结构，尽管它为 REST Web 服务开发人员提供了额外的工作来支持这两种结构。

在我看来，我更喜欢扁平结构，因为它使 URI 更简单，比如 /students/{userId} 而不是 /users/{userId}/student，但如果 API 很大，那么我认为路由会变得越来越难。不过没有太大区别。您需要记住的另一件事是，在某些情况下，同一个人也可以是学生和教授，例如我认识这样的人。是允许这种混合帐户还是给他们 2 个单独的帐户，这是一个业务和安全决定。从安全角度或至少选择会话的角色，我更喜欢后者。

【讨论】：