为什么惯例说数据库表名应该是单数而RESTful资源应该是复数？

至少在SQL中，数据库表名称应为单数，这是一个非常明确的约定。SELECT * FROM user;请参阅此问题和讨论。

RESTful API资源名称应为复数形式，这也是一个相当明确的约定。GET /users/123并POST /users看到这个。

在最简单的数据库支持的API中，URL中的资源名称将是表，URL中的数据元素和请求/响应主体将直接映射到DB中的列。从概念上讲，我认为通过此理论API对数据进行操作与直接通过SQL对数据进行操作之间没有区别。因此，user和之间的命名约定差异users对我来说没有意义。

从概念上来说，当REST API和SQL做相同的事情时，如何证明多元化的合理性？

REST规范（无论您要使用的级别）并非设计为数据库访问权限。它正在尝试使API访问标准化。提到的SQL约定（无论是否要使用它们）在设计时都没有考虑API访问。它们用于编写SQL查询。

因此，这里要解开的问题是API直接映射到数据库的概念理解。我们至少可以追溯到2009年将其描述为反模式。

这是不好的主要原因？描述“此操作如何影响我的数据？”的代码 成为客户代码。

这对API产生了非常糟糕的影响。（不是详尽的清单）

这使得与API集成变得困难

我想象一下创建一个新用户的步骤，记录如下：

1. POST /users { .. }
2. POST /usersettings { .. } 带有一些默认值
3. POST /confirmemails { .. }

但是，如何处理步骤2的失败？这个相同的处理逻辑会复制粘贴到您的API的其他客户端多少次？

这些数据操作通常更容易在服务器端进行排序，同时作为一个单一操作从客户端启动。例如POST /newusersetup。DBA可以将其识别为存储过程，但是API操作可能不仅具有数据库作用。

保护API成为绝望的黑洞

假设您需要合并两个用户帐户。

1. GET /users/1
2. PUT /users/2 { .. }
3. DELETE /users/1

您将如何设置用户权限以允许合并功能同时不允许删除用户？是否删除用户甚至还可以用DELETE /users/1when 表示/usersettings？

应该将API操作视为更高级别（而非数据库）的操作，这些操作可能会导致系统中发生多次更改。

维护变得更加困难

...因为您的客户取决于您的数据库结构。

根据我在这种情况下的经验：

• 您不能重命名或删除现有的表/列。即使它们的功能名称不正确或已不再使用。客户会破产。
• 新功能无法更改现有数据结构，因此，即使其整体上属于现有功能，其数据和功能也常常被人为分离。
• 由于碎片，名称混乱以及无法安全移除的遗留行李，代码库逐渐变得难以理解。
• 除琐碎的变化外，所有变化都变得越来越危险和耗时。
• 系统停滞并最终被替换。

不要将数据库结构直接暴露给客户端...尤其是您没有开发控制权的客户端。使用API​​将客户端范围缩小到仅有效操作。

因此，如果您仅将API用作直接连接到数据库的接口，那么复数形式的麻烦就很少了。对于非一次性实验，我建议花一些时间确定API应该代表的更高级别的操作。当您以这种方式看时，复数API实体名称和单数SQL实体名称之间没有冲突。他们在那里是出于不同的原因。

REST API和SQL并非“做同样的事情”

OP问：

从概念上来说，当REST API和SQL做相同的事情时，如何证明多元化的合理性？

嗯，但是蚂蚱，看来 RESTful接口和SQL表“在做同样的事情”，但是良好的编程习惯告诉我们，在REST API和数据库之间总是存在一个中间层。忽略这一点就是偏离了软件启蒙的道路！:)

因此，RESTful API和SQL表可以很高兴地遵循它们自己的惯用命名约定，这些约定已被详细记录并在其他地方进行了详细讨论。