REST API资源命名约定-用户或用户（多元化） 长版本

对于包括我在内的一些人来说，构建RESTAPI最痛苦和最头痛的部分之一是确定每个资源和伴随的端点的名称

当然，这取决于个人偏好；有些事情是受到社区鼓励的。例如，包括我在内的大多数人都会将他们的资源名称多元化：

GET /notifications
POST /posts

然而，在有些情况下，多元化似乎并不正确。考虑下面的例子：<代码>用户< /C>基本上代表登录用户，而不是整个<代码>用户< /Cord>资源：

仅与经过身份验证的用户相关的端点

// Phone Verification
POST /user/phone/request
POST /user/phone/resend
POST /user/phone/verify

// User creation based on authenticated and verified phone
POST /user

// Update authenticated user's profile
PUT /user

// Delete the authenticated user
DELETE /user

// Add/remove the authenticated user's profile image
POST /user/image
DELETE /user/image

// Update the authenticated user's device token
PUT /device/token

访问整个用户资源的端点

GET /user
GET /user/{id|self}

在上面的例子中，对我来说，感觉单一的

用户

资源名称更适合大多数端点，

用户

指的是经过身份验证的

用户

，而不是整个

用户数据库

。但是，另一方面，让

GET/user

返回所有用户似乎是完全错误的

因此，我现在在

用户

和

用户

之间左右为难——在我看来，两者都有很强的论据，但我非常欢迎其他人对此事发表意见

---

短版

TLDR-简单地说，考虑下面两个端点：

// Get all users
GET /users

// Update the authenticated user's device token
PUT /user/device

在我看来，以上两项都是正确的。上面的问题是，我不可能同时拥有

用户

和

用户

，我认为必须是其中之一

困境；当资源引用整个用户数据库时，为什么要使用

user

？当资源仅指经过身份验证的用户时，为什么要使用

用户

我无法理解这一点。。。有人对此有什么想法吗？或者，更好的是，我提出的端点结构的替代解决方案

---

更新 经过深思熟虑，我想出了一个替代方案，但我仍然不能100%确定，因为我不太喜欢使用

auth

资源名称

考虑这一点：

// auth = authenticated user
// users = users collection

POST /auth/request
POST /auth/resend
POST /auth/verify

POST /auth
PUT /auth
DELETE /auth

POST /auth/image
DELETE /auth/image

PUT /auth/device/token

GET /users
GET /users/{id}

---

在这件事上显然有不同的意见，下面的答案包含了我个人的观点。 归根结底，这一切都是非常主观的，取决于人们看待某种（类型）资源的方式

当资源引用整个用户时，为什么要使用

user

数据库

在我看来，对于包含多个资源的端点，永远不要使用单数。
然而，有些人认为，我们应该坚持所有资源的奇点，主要是为了简单和统一

当资源仅引用 认证用户

你会发现在这方面有很多不同的观点，但共识和最广泛采用的通常是坚持复数，除了只能包含单个项目的资源（例如，仅包含一个化身的用户配置文件）。
此外，由于对

用户使用单数形式

资源按照上述逻辑是没有意义的，因此我们不希望混合使用单数和复数名称

// Update the authenticated user's device token
PUT /user/device

您可以将“更新已验证用户的设备令牌”解释如下：

---

将设备令牌添加到

用户

资源集合的

用户

实体。

如果您的API支持查看其他用户的设备数据，则API可以类似于/users/$user\u id/设备

然而，当您总是需要获取当前登录用户的设备信息时，API可以是/devices（暗示为当前用户）

---

i、 在我看来，只要您只有一个可访问的父资源（例如，在本例中，当前用户始终是单数），您就可以跳过API URL中的该资源。

我完全同意，在集合中使用复数是正常的，我已经练习了多年。我一直在思考这个问题，认为我的问题是与经过身份验证的用户相关的资源。这个端点不适合我

PUT/users/device

，因为从技术上讲，您应该声明您正在编辑设备的资源上的哪个用户，例如

PUT/users/self/device

。我现在想我应该这样做

/auth/device

，其中

auth

表示经过身份验证的用户（单数）。你对此有何看法？请不要随意使用粗体字和短语。读起来很烦人。@BenCarey我同意

PUT/users/device

感觉不对。无论是

PUT/users/id/device

还是

/auth/device

都会更好。我个人更喜欢第一种选择，因为我觉得没有必要为授权用户指定一个单独的资源名称。@LaurensDeprost-欢迎来到我的困境-我不想为经过身份验证的用户指定单独的资源<代码>身份验证，因为这似乎有些过分了。但是，拥有

PUT/users/{id | self}/device

似乎并不正确，因为您无法更新其他用户的设备。换句话说，端点将始终是

/users/self/device

。我想这并不是世界末日，但作为一个完美主义者，这真的让我很恼火，因为这似乎并不正确。。。啊。你怎么看？@BenCarey我理解你的困境，但我仍然会以

/users/id/device

的形式实施它。这似乎是最宁静的方式。