对我来说，复数操作集合，而单数操作集合中的项。

集合允许使用GET / POST / DELETE方法

项允许GET / PUT / DELETE方法

例如

POST on /students将在学校增加一名新学生。

DELETE on /students将删除学校中的所有学生。

DELETE /student/123将从学校删除学生123。

这可能感觉不重要，但一些工程师有时会忘记id。如果路由总是复数并执行DELETE，可能会意外擦除数据。而在奇异点上缺少id则会返回404路由。

为了进一步扩展示例，如果API应该公开多所学校，那么如下所示

DELETE on /school/abc/students将删除学校abc中的所有学生。

选择正确的词语有时本身就是一个挑战，但我喜欢保持语汇的多样性。例如cart_items或cart/items感觉正确。相反，删除购物车，删除的是购物车对象本身，而不是购物车中的物品;)。

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

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

GET /resources?Id=123

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

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

GET /resource?Id=123

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

为了简单和一致性，我更喜欢使用单数形式。

例如，考虑以下url:

/客户/ 1

我将把客户视为客户集合，但是为了简单起见，集合部分被删除了。

另一个例子:

/设备/ 1

在这种情况下，equipment不是正确的复数形式。因此，为了简单起见，将其视为设备集合和删除集合，使其与客户案例一致。

为什么不遵循数据库表名的流行趋势，通常采用单数形式?有过这样的经历，让我们重新使用。

表命名困境:单数和复数名称

我很惊讶地看到这么多人会追随复数名词的潮流。在实现单数到复数的转换时，是否注意到不规则复数名词?你喜欢疼痛吗?

看到 http://web2.uvcs.uvic.ca/elc/studyzone/330/grammar/irrplu.htm

不规则复数有很多种，但以下是最常见的:

形成复数形式的

Ends with -fe   Change f to v then Add -s   
    knife   knives 
    life   lives 
    wife   wives
Ends with -f    Change f to v then Add -es  
    half   halves 
    wolf   wolves
    loaf   loaves
Ends with -o    Add -es 
    potato   potatoes
    tomato   tomatoes
    volcano   volcanoes
Ends with -us   Change -us to -i    
    cactus   cacti
    nucleus   nuclei
    focus   foci
Ends with -is   Change -is to -es   
    analysis   analyses
    crisis   crises
    thesis   theses
Ends with -on   Change -on to -a    
    phenomenon   phenomena
    criterion   criteria
ALL KINDS   Change the vowel or Change the word or Add a different ending   
     man   men
     foot   feet
     child   children
     person   people
     tooth   teeth
     mouse   mice
 Unchanging Singular and plural are the same    
     sheep deer fish (sometimes)

复数

简单-所有url都以相同的前缀开头 逻辑——订单/获取订单的索引列表。 标准——被绝大多数公共和私有api广泛采用的标准。

例如:

GET /resources -返回资源项的列表

POST /resources -创建一个或多个资源项

PUT /resources—更新一个或多个资源项

PATCH /resources—部分更新一个或多个资源项

DELETE /resources -删除所有资源项

对于单个资源项:

GET /resources/:id -根据:id参数返回一个特定的资源项

POST /resources/:id—用指定的id创建一个资源项(需要验证)

PUT /resources/:id -更新一个特定的资源项

PATCH /resources/:id—部分更新特定的资源项

DELETE /resources/:id -删除指定的资源项

对于单数的提倡者，可以这样想:你会向某人要一份订单，并期待一件事，还是一份清单?那么，当您键入/订单时，为什么期望服务返回一列东西呢?