我更喜欢同时使用复数(/resources)和单数(/resource/{id})，因为我认为它更清楚地区分了处理资源集合和处理单个资源之间的逻辑。

作为一个重要的副作用，它还可以帮助防止某些人错误地使用API。例如，考虑这样一种情况，用户错误地试图通过将Id指定为如下参数来获取资源:

GET /resources?Id=123

在本例中，我们使用复数形式，服务器很可能会忽略Id参数并返回所有资源的列表。如果用户不小心，他会认为调用成功，并使用列表中的第一个资源。

另一方面，当使用单数形式时:

GET /resource?Id=123

服务器很可能会返回一个错误，因为Id没有以正确的方式指定，并且用户将不得不意识到某些事情是错误的。

这两种表示都很有用。在相当长的一段时间里，我为了方便而使用单数，屈折变化可能会很困难。根据我在开发严格的单一REST api方面的经验，使用端点的开发人员对结果可能是什么形状缺乏确定性。我现在更倾向于使用最能描述反应形式的术语。

如果您的所有资源都是顶级的，那么您可以使用单一表示。避免变化是一个巨大的胜利。

如果您正在使用任何类型的深度链接来表示关系上的查询，那么使用您的API编写程序的开发人员可以通过使用更严格的约定来获得帮助。

我的习惯是，URI中的每一层深度都描述了与父资源的交互，而完整的URI应该隐式地描述正在检索的内容。

假设我们有以下模型。

interface User {
    <string>id;
    <Friend[]>friends;
    <Manager>user;
}

interface Friend {
    <string>id;
    <User>user;
    ...<<friendship specific props>>
}

如果我需要提供一个资源，允许客户端获得特定用户的特定朋友的管理器，它可能看起来像这样:

GET /用户/ {id} /朋友/ {friendId} /经理

下面是更多的例子:

GET /users - list the user resources in the global users collection POST /users - create a new user in the global users collection GET /users/{id} - retrieve a specific user from the global users collection GET /users/{id}/manager - get the manager of a specific user GET /users/{id}/friends - get the list of friends of a user GET /users/{id}/friends/{friendId} - get a specific friend of a user LINK /users/{id}/friends - add a friend association to this user UNLINK /users/{id}/friends - remove a friend association from this user

注意每个级别是如何映射到一个可以被操作的父级的。为同一个对象使用不同的父对象是违反直觉的。在GET /resource/123处检索资源时，没有指示应该在POST /resources处创建新资源

从API使用者的角度来看，端点应该是可预测的

在理想的情况下……

GET /resources should return a list of resources. GET /resource should return a 400 level status code. GET /resources/id/{resourceId} should return a collection with one resource. GET /resource/id/{resourceId} should return a resource object. POST /resources should batch create resources. POST /resource should create a resource. PUT /resource should update a resource object. PATCH /resource should update a resource by posting only the changed attributes. PATCH /resources should batch update resources posting only the changed attributes. DELETE /resources should delete all resources; just kidding: 400 status code DELETE /resource/id/{resourceId}

这种方法最灵活，功能最丰富，但开发起来也最耗时。因此，如果您很着急(软件开发总是这样)，只需命名您的端点资源或复数形式的资源。我更喜欢单数形式，因为它让你可以选择内省和编程计算，因为不是所有的复数形式都以's'结尾。

说了这么多，不管出于什么原因，最常用的实践开发人员选择使用复数形式。这是我最终选择的路线，如果你看看流行的api，如github和twitter，这就是他们所做的。

决定的一些标准可以是:

我的时间限制是什么? 我将允许我的消费者做哪些操作? 请求和结果有效负载是什么样子的? 我是否希望能够在代码中使用反射并解析URI ?

所以这取决于你。无论你做什么都要坚持。

对于命名惯例，通常可以安全地说“只选择一个并坚持使用它”，这是有道理的。

然而，在不得不向许多人解释REST之后，将端点表示为文件系统上的路径是最具表现力的方法。 它是无状态的(文件存在或不存在)，分层的，简单的，熟悉的-您已经知道如何访问静态文件，无论是本地还是通过http。

在这种情况下，语言规则只能让你达到以下效果:

一个目录可以包含多个文件和/或子目录，因此它的名称应该是复数形式。

但我喜欢妳 不过，另一方面，这是您的目录，如果您愿意，您可以将其命名为“一个资源或多个资源”。这不是真正重要的事情。

重要的是，如果您将一个名为“123”的文件放在名为“resourceS”的目录下(结果是/resourceS/123)，那么您就不能期望通过/resource/123访问它。

不要试图让它变得比原来更聪明——根据你当前访问的资源数量从复数变成单数对某些人来说可能是美观的，但这并不是有效的，在一个等级系统中也没有意义。

注意:技术上，你可以创建“符号链接”，这样/resources/123也可以通过/resource/123访问，但前者仍然必须存在!

在所有方法中使用复数至少在一个方面更实用: 如果你正在使用Postman(或类似的工具)开发和测试资源API，当从GET切换到PUT再切换到POST时，你不需要编辑URI。

使用/resources的前提是它表示“所有”资源。如果执行GET /resources，则可能返回整个集合。通过发布到/resources，您将添加到集合中。

但是，单个资源在/resource上可用。如果执行GET /resource请求，则可能会出错，因为这个请求没有任何意义，而/resource/123则完全有意义。

使用/resource而不是/resources类似于使用文件系统和文件集合，/resource是包含单独的123,456个文件的“目录”。

没有对错之分，你喜欢什么就去做什么。