blocks|key|2948941|text|使用/resources的前提是它代表“所有”资源。如果执行GET+/resources，很可能会返回整个集合。通过POSTing+to+/resources，您正在向集合中添加内容。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|2948942|但是，单个资源可以在/resource上找到。如果你做一个GET+/resource，你很可能会出错，因为这个请求没有任何意义，而/resource/123非常有意义。|2948943|使用/resource而不是/resources类似于您使用文件系统和文件集合的情况，/resource是包含单个123和456文件的“目录”。|2948944|没有一种方法是对或错的，请选择你最喜欢的。|2948945|entityMap^0|2|A|U|E|1X|A|0|T|D|1T|D|0|2|9|E|A|17|9|1L|3|1P|3|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]|$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@$9|V|A|W|B|C]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|Z|8|@$9|10|A|11|B|C]|$9|12|A|13|B|C]|$9|14|A|15|B|C]|$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1A|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|1B|8|@]|D|@]|E|$]]]|M|$]]

The premise of using <code>/resources</code> is that it is representing "all" resources. If you do a <code>GET /resources</code>, you will likely return the entire collection. By POSTing to <code>/resources</code>, you are adding to the collection.

However, the individual resources are available at /resource. If you do a <code>GET /resource</code>, you will likely error, as this request doesn't make any sense, whereas <code>/resource/123</code> makes perfect sense.

Using <code>/resource</code> instead of <code>/resources</code> is similar to how you would do this if you were working with, say, a file system and a collection of files and <code>/resource</code> is the "directory" with the individual <code>123</code>, <code>456</code> files in it.

Neither way is right or wrong, go with what you like best.

blocks|key|257501|text|我也看不出这样做的意义，我认为这不是最好的URI设计。作为RESTful服务的用户，无论我是访问列表还是列表中的特定资源，我都希望列表资源具有相同的名称。无论您是要使用列表资源还是特定资源，都应该使用相同的标识符。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|257502|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I don't see the point in doing this either and I think it is not the best URI design. As a user of a RESTful service I'd expect the list resource to have the same name no matter whether I access the list or specific resource 'in' the list. You should use the same identifiers no matter whether you want use the list resource or a specific resource.

blocks|key|3162901|text|虽然最流行的做法是使用复数的RESTful+apis，例如/api/resources/123，但有一种特殊情况下，我发现使用单数名称比使用复数名称更合适/更有表现力。这是一对一关系的情况。具体地说，如果目标项是一个值对象(在域驱动的设计范例中)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3162902|让我们假设每个资源都有一个一对一的accessLog，它可以被建模为一个值对象，即不是一个实体，因此没有ID。它可以被表示为/api/resources/123/accessLog。通常的动词(POST，PUT，DELETE，GET)可以恰当地表达意图，以及关系确实是一对一的事实。|3162903|entityMap^0|T|I|0|H|9|1Q|S|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@$9|N|A|O|B|C]|$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|R|8|@]|D|@]|E|$]]]|I|$]]

Whereas the most prevalent practice are RESTful apis where plurals are used e.g. <code>/api/resources/123</code> , there is one special case where I find use of a singular name more appropriate/expressive than plural names. It is the case of one-to-one relationships. Specifically if the target item is a value object(in Domain-driven-design paradigm).

Let us assume every resource has a one-to-one <code>accessLog</code> which could be modeled as a value object i.e not an entity therefore no ID. It could be expressed as <code>/api/resources/123/accessLog</code>. The usual verbs (POST, PUT, DELETE, GET) would appropriately express the intent and also the fact that the relationship is indeed one-to-one.

blocks|key|3162973|text|为什么不遵循数据库表名的流行趋势，因为单数形式是被普遍接受的？在那里，完成了--让我们重用它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3162974|Table+Naming+Dilemma:+Singular+vs.+Plural+Names|offset|length|3162975|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/338156/table-naming-dilemma-singular-vs-plural-names^0|0|0|1B|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Why not follow the prevalent trend of database table names, where a singular form is generally accepted? Been there, done that -- let's reuse.

<a href="https://stackoverflow.com/questions/338156/table-naming-dilemma-singular-vs-plural-names">Table Naming Dilemma: Singular vs. Plural Names</a>

blocks|key|259876|text|对我来说，最好有一个可以直接映射到代码(易于自动化)的模式，这主要是因为代码将是两端的东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|259877|GET++/orders++++++++++<--->+orders+
POST+/orders++++++++++<--->+orders.push(data)
GET++/orders/1++++++++<--->+orders[1]
PUT++/orders/1++++++++<--->+orders[1]+=+data
GET++/orders/1/lines++<--->+orders[1].lines
POST+/orders/1/lines++<--->+orders[1].lines.push(data)+|code-block|syntax|javascript|259878|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

For me is better to have a schema that you can map directly to code (easy to automate), mainly because code is what is going to be at both ends. 

<pre><code>GET /orders &lt;---&gt; orders 
POST /orders &lt;---&gt; orders.push(data)
GET /orders/1 &lt;---&gt; orders[1]
PUT /orders/1 &lt;---&gt; orders[1] = data
GET /orders/1/lines &lt;---&gt; orders[1].lines
POST /orders/1/lines &lt;---&gt; orders[1].lines.push(data) 
</code></pre>

blocks|key|3163101|text|从API使用者的角度来看，端点应该是可预测的，因此|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3163102|理想情况下..。|3163103|3163104|GET+/resources应该返回一个资源列表。|ordered-list-item|offset|length|style|CODE|3163105|GET+/resource应返回400级状态code.|3163106|GET+/resources/id/{resourceId}应返回具有一个resource.|3163107|GET+/resource/id/{resourceId}的集合应返回资源object.|3163108|POST+/resources应批量创建resources.|3163109|POST+/resource应创建resource.|3163110|PUT+/resource应更新资源object.|3163111|PATCH+/resource应仅通过发布已更改的attributes.|3163112|PATCH+/resources来更新资源应仅批量更新资源应仅发布已更改的attributes.|3163113|DELETE+/resources应删除所有资源；开个玩笑:+400个状态code|3163114|DELETE+/resource/id/{resourceId}|3163115|3163116|这种方法是最灵活和功能最丰富的，但也是最耗时的开发。因此，如果您赶时间(软件开发总是如此)，只需将您的端点命名为resource或复数形式resources。我更喜欢单数形式，因为它让你可以选择以编程的方式反省和评估，因为并不是所有的复数形式都以“s”结尾。|3163117|话虽如此，不管出于什么原因，最常用的实践开发人员选择的是使用复数形式。这是我最终选择的路线，如果你看看像github和twitter这样的流行的apis，这就是他们所做的。|3163118|决定的一些标准可能是：|3163119|3163120|我的时间限制是什么？|3163121|我将允许我的使用者执行哪些操作？|3163122|请求和结果负载是什么样子？|3163123|我是否希望能够在代码中使用反射和分析URI？|3163124|3163125|所以就看你的了。无论你做什么，都要始终如一。|3163126|entityMap^0|0|0|0|0|E|0|0|D|0|0|U|0|0|T|0|0|F|0|0|E|0|0|D|0|0|F|0|0|G|0|0|H|0|0|W|0|0|1K|8|1X|9|0|1G|6|1N|7|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1R|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|1T|8|@$H|1U|I|1V|J|K]]|9|@]|A|$]]|$1|L|3|M|5|G|7|1W|8|@$H|1X|I|1Y|J|K]]|9|@]|A|$]]|$1|N|3|O|5|G|7|1Z|8|@$H|20|I|21|J|K]]|9|@]|A|$]]|$1|P|3|Q|5|G|7|22|8|@$H|23|I|24|J|K]]|9|@]|A|$]]|$1|R|3|S|5|G|7|25|8|@$H|26|I|27|J|K]]|9|@]|A|$]]|$1|T|3|U|5|G|7|28|8|@$H|29|I|2A|J|K]]|9|@]|A|$]]|$1|V|3|W|5|G|7|2B|8|@$H|2C|I|2D|J|K]]|9|@]|A|$]]|$1|X|3|Y|5|G|7|2E|8|@$H|2F|I|2G|J|K]]|9|@]|A|$]]|$1|Z|3|10|5|G|7|2H|8|@$H|2I|I|2J|J|K]]|9|@]|A|$]]|$1|11|3|12|5|G|7|2K|8|@$H|2L|I|2M|J|K]]|9|@]|A|$]]|$1|13|3|14|5|G|7|2N|8|@$H|2O|I|2P|J|K]]|9|@]|A|$]]|$1|15|3|-4|5|6|7|2Q|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|2R|8|@$H|2S|I|2T|J|K]|$H|2U|I|2V|J|K]]|9|@]|A|$]]|$1|18|3|19|5|6|7|2W|8|@$H|2X|I|2Y|J|K]|$H|2Z|I|30|J|K]]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|31|8|@]|9|@]|A|$]]|$1|1C|3|-4|5|6|7|32|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|G|7|33|8|@]|9|@]|A|$]]|$1|1F|3|1G|5|G|7|34|8|@]|9|@]|A|$]]|$1|1H|3|1I|5|G|7|35|8|@]|9|@]|A|$]]|$1|1J|3|1K|5|G|7|36|8|@]|9|@]|A|$]]|$1|1L|3|-4|5|6|7|37|8|@]|9|@]|A|$]]|$1|1M|3|1N|5|6|7|38|8|@]|9|@]|A|$]]|$1|1O|3|-4|5|6|7|39|8|@]|9|@]|A|$]]]|1P|$]]

From the API consumer's perspective, the endpoints should be predictable so

Ideally...

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

This approach is the most flexible and feature rich, but also the most time consuming to develop. So, if you're in a hurry (which is always the case with software development) just name your endpoint <code>resource</code> or the plural form <code>resources</code>. I prefer the singular form because it gives you the option to introspect and evaluate programmatically since not all plural forms end in 's'.

Having said all that, for whatever reason the most commonly used practice developer's have chosen is to use the plural form. This is ultimately the route I have chosen and if you look at popular apis like <code>github</code> and <code>twitter</code>, this is what they do. 

Some criteria for deciding could be:

<ol>
<li>What are my time constraints? </li>
<li>What operations will I allow my consumers to do?</li>
<li>What does the request and result payload look like?</li>
<li>Do I want to be able to use reflection and parse the URI in my code?</li>
</ol>

So it's up to you. Just whatever you do be consistent.

blocks|key|261821|text|我的两点意见:将时间从复数变为单数或反之亦然的方法是在浪费CPU周期。我可能是个守旧的人，但在我那个时代，喜欢的东西都是一样的。如何查找与人相关的方法？任何常规的表达方式都不会同时覆盖人和人，而不会产生不良的副作用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|261822|英语复数可以是非常随意的，它们不必要地阻碍了代码。坚持一种命名约定。计算机语言应该是数学清晰度，而不是模仿自然语言。|261823|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

My two cents: methods who spend their time changing from plural to singular or viceversa are a waste of CPU cycles. I may be old-school, but in my time like things were called the same. How do I look up methods concerning people? No regular expresion will cover both person and people without undesirable side effects.

English plurals can be very arbitrary and they encumber the code needlessly. Stick to one naming convention. Computer languages were supposed to be about mathematical clarity, not about mimicking natural language.

blocks|key|3163233|text|复数|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3163234|3163235|Simple+-所有urls都以相同的prefix|unordered-list-item|3163236|Logical开头-+orders/获取orders.|CODE|3163237|Standard的索引列表-最广泛采用的标准，紧随其后的是绝大多数公共和私有API。|3163238|3163239|例如：|3163240|GET++++/resources+-返回资源项列表|3163241|POST+++/resources+-创建一个或多个资源项|3163242|PUT++++/resources+-更新一个或多个资源项|3163243|PATCH++/resources+-部分更新一个或多个资源项|3163244|DELETE+/resources+-删除所有资源项|3163245|对于单个资源项：|3163246|GET++++/resources/:id+-根据:id参数返回特定资源项|3163247|POST+++/resources/:id+-使用指定的id创建一个资源项(需要验证)|3163248|PUT++++/resources/:id+-更新特定资源项|3163249|PATCH++/resources/:id+-部分更新特定资源项|3163250|DELETE+/resources/:id+-删除特定资源项|3163251|对于singular的拥护者，你会这样想:你会向某人要一个order，然后期待一件事情，还是一系列事情？那么，当您输入/order时，为什么要期望服务返回一个内容列表呢|3163252|entityMap^0|0|2|0|0|0|6|0|0|7|B|7|0|0|8|0|0|0|0|H|0|0|H|0|0|H|0|0|H|0|0|H|0|0|0|L|P|3|0|0|L|0|0|L|0|0|L|0|0|L|0|T|5|1N|6|0^^$0|@$1|2|3|4|5|6|7|1H|8|@$9|1I|A|1J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|1K|8|@]|D|@]|E|$]]|$1|G|3|H|5|I|7|1L|8|@$9|1M|A|1N|B|C]]|D|@]|E|$]]|$1|J|3|K|5|I|7|1O|8|@$9|1P|A|1Q|B|C]|$9|1R|A|1S|B|L]]|D|@]|E|$]]|$1|M|3|N|5|I|7|1T|8|@$9|1U|A|1V|B|C]]|D|@]|E|$]]|$1|O|3|-4|5|6|7|1W|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1X|8|@]|D|@]|E|$]]|$1|R|3|S|5|6|7|1Y|8|@$9|1Z|A|20|B|L]]|D|@]|E|$]]|$1|T|3|U|5|6|7|21|8|@$9|22|A|23|B|L]]|D|@]|E|$]]|$1|V|3|W|5|6|7|24|8|@$9|25|A|26|B|L]]|D|@]|E|$]]|$1|X|3|Y|5|6|7|27|8|@$9|28|A|29|B|L]]|D|@]|E|$]]|$1|Z|3|10|5|6|7|2A|8|@$9|2B|A|2C|B|L]]|D|@]|E|$]]|$1|11|3|12|5|6|7|2D|8|@]|D|@]|E|$]]|$1|13|3|14|5|6|7|2E|8|@$9|2F|A|2G|B|L]|$9|2H|A|2I|B|L]]|D|@]|E|$]]|$1|15|3|16|5|6|7|2J|8|@$9|2K|A|2L|B|L]]|D|@]|E|$]]|$1|17|3|18|5|6|7|2M|8|@$9|2N|A|2O|B|L]]|D|@]|E|$]]|$1|19|3|1A|5|6|7|2P|8|@$9|2Q|A|2R|B|L]]|D|@]|E|$]]|$1|1B|3|1C|5|6|7|2S|8|@$9|2T|A|2U|B|L]]|D|@]|E|$]]|$1|1D|3|1E|5|6|7|2V|8|@$9|2W|A|2X|B|L]|$9|2Y|A|2Z|B|L]]|D|@]|E|$]]|$1|1F|3|-4|5|6|7|30|8|@]|D|@]|E|$]]]|1G|$]]

Plural

<ul>
<li>Simple - all urls start with the same prefix</li>
<li>Logical - <code>orders/</code> gets an index list of orders.</li>
<li>Standard - Most widely adopted standard followed by the overwhelming majority of public and private APIs.</li>
</ul>

For example:

<code>GET /resources</code> - returns a list of resource items

<code>POST /resources</code> - creates one or many resource items

<code>PUT /resources</code> - updates one or many resource items

<code>PATCH /resources</code> - partially updates one or many resource items 

<code>DELETE /resources</code> - deletes all resource items

And for single resource items:

<code>GET /resources/:id</code> - returns a specific resource item based on <code>:id</code> parameter

<code>POST /resources/:id</code> - creates one resource item with specified id (requires validation)

<code>PUT /resources/:id</code> - updates a specific resource item

<code>PATCH /resources/:id</code> - partially updates a specific resource item

<code>DELETE /resources/:id</code> - deletes a specific resource item

To the advocates of singular, think of it this way: Would you ask a someone for an <code>order</code> and expect one thing, or a list of things? So why would you expect a service to return a list of things when you type <code>/order</code>?

blocks|key|2949394|text|单数|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2949395|+irregular++Things可以有不规则的复数名称。有时他们没有。但单数名称总是存在的。|offset|length|style|BOLD|2949396|例如，CustomerAddresses上的CustomerAddress|2949397|考虑这个相关的资源。|2949398|这种/order/12/orderdetail/12比/orders/12/orderdetails/4更具可读性和逻辑性。|CODE|2949399|数据库表|2949400|资源表示一个实体，如数据库表。它应该有一个逻辑上的单数名称。下面是表名的answer。|2949401|类映射|2949402|类总是单数的。ORM工具生成与类名相同的表。随着越来越多的工具被使用，单数名称正在成为一种标准。|2949403|阅读有关A+REST+API+Developer's+Dilemma的更多信息|2949404|对于没有单数名称的事物|2949405|在trousers和sunglasses的情况下，它们似乎没有一个单独的对应物。它们是众所周知的，而且它们的用法似乎是单数。就像一双鞋。考虑将类文件命名为Shoe或Shoes。在这里，通过使用这些名称，必须将其视为一个单一实体。你看不到任何人买一只鞋就是为了得到URL|2949406|/shoe/23|code-block|syntax|javascript|2949407|我们必须把Shoes看作一个单一的实体。|2949408|参考：Top+6+REST+Naming+Best+Practices|2949409|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/5841297/1097600|1|https://metamug.com/article/rest-api-developers-dilemma.php|2|https://metamug.com/article/rest-api-naming-best-practices.html#1-using-commonly-used-nouns-as-resource-names^0|0|0|B|0|0|0|2|O|R|P|0|0|10|6|0|0|0|0|4|U|1|0|0|1|8|A|A|25|4|2A|5|0|0|5|5|0|3|W|2|0^^$0|@$1|2|3|4|5|6|7|1N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1O|8|@$D|1P|E|1Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1S|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1T|8|@$D|1U|E|1V|F|N]|$D|1W|E|1X|F|N]]|9|@]|A|$]]|$1|O|3|P|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1Z|8|@]|9|@$D|20|E|21|1|22]]|A|$]]|$1|S|3|T|5|6|7|23|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|24|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|25|8|@]|9|@$D|26|E|27|1|28]]|A|$]]|$1|Y|3|Z|5|6|7|29|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|2A|8|@$D|2B|E|2C|F|N]|$D|2D|E|2E|F|N]|$D|2F|E|2G|F|N]|$D|2H|E|2I|F|N]]|9|@]|A|$]]|$1|12|3|13|5|14|7|2J|8|@]|9|@]|A|$15|16]]|$1|17|3|18|5|6|7|2K|8|@$D|2L|E|2M|F|N]]|9|@]|A|$]]|$1|19|3|1A|5|6|7|2N|8|@]|9|@$D|2O|E|2P|1|2Q]]|A|$]]|$1|1B|3|-4|5|6|7|2R|8|@]|9|@]|A|$]]]|1C|$1D|$5|1E|1F|1G|A|$1H|1I]]|1J|$5|1E|1F|1G|A|$1H|1K]]|1L|$5|1E|1F|1G|A|$1H|1M]]]]

<h2>Singular</h2>

Convenience 
Things can have irregular plural names. Sometimes they don't have one.
But Singular names are always there.

e.g. CustomerAddress over CustomerAddresses

Consider this related resource.

This <code>/order/12/orderdetail/12</code> is more readable and logical than <code>/orders/12/orderdetails/4</code>.

<h3>Database Tables</h3>

A resource represents an entity like a database table. 
It should have a logical singular name.
Here's the <a href="https://stackoverflow.com/a/5841297/1097600">answer</a> over table names.

<h3>Class Mapping</h3>

Classes are always singular. ORM tools generate tables with the same names as class names. As more and more tools are being used, singular names are becoming a standard.

Read more about <a href="https://metamug.com/article/rest-api-developers-dilemma.php" rel="noreferrer">A REST API Developer's Dilemma</a> 

<h3>For things without singular names</h3>

In the case of <code>trousers</code> and <code>sunglasses</code>, they don't seem to have a singular counterpart. They are commonly known and they appear to be singular by use. Like a pair of shoes. Think about naming the class file <code>Shoe</code> or <code>Shoes</code>. Here these names must be considered as a singular entity by their use. You don't see anyone buying a single shoe to have the URL as 

<pre><code>/shoe/23
</code></pre>

We have to see <code>Shoes</code> as a singular entity. 

Reference: <a href="https://metamug.com/article/rest-api-naming-best-practices.html#1-using-commonly-used-nouns-as-resource-names" rel="noreferrer">Top 6 REST Naming Best Practices</a>

blocks|key|257728|text|对于命名约定，通常可以放心地说“选择一个并坚持使用它”，这是有意义的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|257729|然而，在不得不向许多人解释REST之后，将端点表示为文件系统上的路径是最具表现力的方式。|offset|length|style|BOLD|257730|它是无状态的(文件存在或不存在)，分层的，简单的，熟悉的-你已经知道如何访问静态文件，无论是本地访问还是通过http访问。|257731|在这种情况下，语言规则只能让你做到以下几点：|257732|257733|目录可以包含多个文件和/或子目录，因此其名称应为复数形式。|blockquote|257734|257735|257736|我喜欢这样。|257737|不过，从另一方面来说--这是你的目录，如果你愿意的话，你可以把它命名为"a-resource-or-multiple-resources“。这并不是真正重要的事情。|257738|重要的是，如果您将名为"123“的文件放在名为"resourceS”的目录下(结果是/resourceS/123)，那么您就不能期望通过/resource/123访问它。|CODE|257739|不要试图让它变得更智能--根据当前访问的资源数量从复数更改为单数可能会让一些人觉得美观，但这并不有效，而且在hierarchical系统中也没有意义。|257740|注意:从技术上讲，您可以创建“符号链接”，这样也可以通过/resource/123__访问/resources/123，但前者仍然必须存在！|257741|entityMap^0|0|W|C|0|0|1P|0|0|M|0|0|0|T|0|0|0|0|6|0|0|2A|0|0|2D|16|E|1W|D|0|0|23|0|0|1Y|S|D|19|E|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@$D|16|E|17|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|18|8|@$D|19|E|1A|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1B|8|@$D|1C|E|1D|F|G]]|9|@]|A|$]]|$1|L|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]|$1|M|3|N|5|O|7|1F|8|@$D|1G|E|1H|F|G]]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1K|8|@$D|1L|E|1M|F|G]]|9|@]|A|$]]|$1|T|3|U|5|6|7|1N|8|@$D|1O|E|1P|F|G]]|9|@]|A|$]]|$1|V|3|W|5|6|7|1Q|8|@$D|1R|E|1S|F|G]|$D|1T|E|1U|F|X]|$D|1V|E|1W|F|X]]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1X|8|@$D|1Y|E|1Z|F|G]]|9|@]|A|$]]|$1|10|3|11|5|6|7|20|8|@$D|21|E|22|F|G]|$D|23|E|24|F|X]|$D|25|E|26|F|X]]|9|@]|A|$]]|$1|12|3|-4|5|6|7|27|8|@]|9|@]|A|$]]]|13|$]]

With naming conventions, it's usually safe to say "just pick one and stick to it", which makes sense.

However, after having to explain REST to lots of people, representing endpoints as paths on a file system is the most expressive way of doing it. 
It is stateless (files either exist or don't exist), hierarchical, simple, and familiar - you already knows how to access static files, whether locally or via http.

And within that context, linguistic rules can only get you as far as the following:

<blockquote>
 A directory can contain multiple files and/or sub-directories, and therefore its name should be in plural form.
</blockquote>

And I like that. 
Although, on the other hand - it's your directory, you can name it "a-resource-or-multiple-resources" if that's what you want. That's not really the important thing.

What's important is that if you put a file named "123" under a directory named "resourceS" (resulting in <code>/resourceS/123</code>), you cannot then expect it to be accessible via <code>/resource/123</code>.

Don't try to make it smarter than it has to be - changing from plural to singluar depending on the count of resources you're currently accessing may be aesthetically pleasing to some, but it's not effective and it doesn't make sense in a hierarchical system.

Note: Technically, you can make "symbolic links", so that <code>/resources/123</code> can also be accessed via <code>/resource/123</code>, but the former still has to exist!

blocks|key|3163345|text|将复数用于所有方法至少在一个方面更实用:如果您正在使用Postman+(或类似工具)开发和测试资源API，则在从GET切换到PUT再到POST时不需要编辑URI。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3163346|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Using plural for all methods is more practical at least in one aspect: 
if you're developing and testing a resource API using Postman (or similar tool), you don't need to edit the URI when switching from GET to PUT to POST etc.

blocks|key|2949481|text|为了简单和一致，我更喜欢使用单数形式。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2949482|例如，考虑以下url：|2949483|/客户/1|2949484|我将把customer视为客户集合，但为了简单起见，集合部分被删除了。|2949485|另一个例子：|2949486|/设备/1|2949487|在这种情况下，equipments不是正确的复数形式。因此，为了简单起见，将其视为设备集合并删除集合，使其与客户案例一致。|2949488|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

I prefer using singular form for both simplicity and consistency.

For example, considering the following url:

/customer/1

I will treat customer as customer collection, but for simplicity, the collection part is removed.

Another example:

/equipment/1

In this case, equipments is not the correct plural form. So treating it as a equipment collection and removing collection for simplicity makes it consistent with the customer case.

blocks|key|263202|text|对我来说，复数操作集合，而单数操作该集合内的项。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|263203|集合允许方法GET+/+POST+/+DELETE|263204|Item允许方法GET+/+PUT+/+DELETE|263205|例如|263206|在/students上发布将在学校中添加一个新学生。|263207|DELETE+on+/students将删除学校中的所有学生。|263208|在/student/123上删除将从学校中删除学生123。|263209|这可能看起来并不重要，但有些工程师有时会忘记id。如果路由始终为复数并执行删除，则可能会意外擦除数据。而缺少单数上的id将返回未找到的404路由。|263210|为了进一步扩展示例，如果API应该公开多所学校，则类似于|263211|DELETE+on+/school/abc/students将删除学校abc中的所有学生。|CODE|263212|有时选择合适的词本身就是一个挑战，但我喜欢保持集合的多样性。例如，cart_items或cart/items感觉是对的。相反，删除cart会删除购物车对象本身，而不是购物车中的项目;)。|263213|entityMap^0|9|2|M|1|0|0|2|0|0|4|8|I|0|0|1|9|0|A|9|0|1|C|0|0|0|A|K|Z|3|0|X|A|18|A|1T|4|0^^$0|@$1|2|3|4|5|6|7|12|8|@$9|13|A|14|B|C]|$9|15|A|16|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|17|8|@$9|18|A|19|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1A|8|@$9|1B|A|1C|B|C]|$9|1D|A|1E|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1F|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|1G|8|@$9|1H|A|1I|B|C]]|D|@]|E|$]]|$1|N|3|O|5|6|7|1J|8|@$9|1K|A|1L|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1M|8|@$9|1N|A|1O|B|C]]|D|@]|E|$]]|$1|R|3|S|5|6|7|1P|8|@]|D|@]|E|$]]|$1|T|3|U|5|6|7|1Q|8|@]|D|@]|E|$]]|$1|V|3|W|5|6|7|1R|8|@$9|1S|A|1T|B|C]|$9|1U|A|1V|B|X]]|D|@]|E|$]]|$1|Y|3|Z|5|6|7|1W|8|@$9|1X|A|1Y|B|X]|$9|1Z|A|20|B|X]|$9|21|A|22|B|X]]|D|@]|E|$]]|$1|10|3|-4|5|6|7|23|8|@]|D|@]|E|$]]]|11|$]]

To me plurals manipulate the collection, whereas singulars manipulate the item inside that collection.

Collection allows the methods GET / POST / DELETE

Item allows the methods GET / PUT / DELETE

For example

POST on /students will add a new student in the school. 

DELETE on /students will remove all the students in the school. 

DELETE on /student/123 will remove student 123 from the school.

It might feel like unimportant but some engineers sometimes forget the id. If the route was always plural and performed a DELETE, you might accidentally wipe your data. Whereas missing the id on the singular will return a 404 route not found.

To further expand the example if the API was supposed to expose multiple schools, then something like

DELETE on /school/abc/students will remove all the students in the school <code>abc</code>. 

Choosing the right word sometimes is a challenge on its own, but I like to maintain plurality for the collection. E.g. <code>cart_items</code> or <code>cart/items</code> feels right. In contrast deleting <code>cart</code>, deletes the cart object it self and not the items within the cart ;).

blocks|key|3163446|text|我很惊讶地看到这么多人会加入复数名词的潮流。在实现单数到复数的转换时，您是否在处理不规则的复数名词？你喜欢痛苦吗？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3163447|请参阅http://web2.uvcs.uvic.ca/elc/studyzone/330/grammar/irrplu.htm|offset|length|3163448|不规则复数有很多种，但最常见的是：|3163449|构成复数形式的名词类型|3163450|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)|code-block|syntax|javascript|3163451|entityMap|0|LINK|mutability|MUTABLE|url|http://web2.uvcs.uvic.ca/elc/studyzone/330/grammar/irrplu.htm^0|0|3|1P|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@$D|Y|E|Z|1|10]]|A|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|12|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|13|8|@]|9|@]|A|$M|N]]|$1|O|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|V]]]]

I am surprised to see that so many people would jump on the plural noun bandwagon. When implementing singular to plural conversions, are you taking care of irregular plural nouns? Do you enjoy pain?

See
<a href="http://web2.uvcs.uvic.ca/elc/studyzone/330/grammar/irrplu.htm" rel="noreferrer">http://web2.uvcs.uvic.ca/elc/studyzone/330/grammar/irrplu.htm</a>

There are many types of irregular plural, but these are the most common:

Noun type Forming the plural Example

<pre><code>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)
</code></pre>

blocks|key|3163484|text|这两种表示都很有用。为了方便起见，我使用单数已经有很长一段时间了，词形变化可能很难。我在开发严格的单一REST+API方面的经验是，使用端点的开发人员对结果的形状缺乏确定性。现在，我更喜欢使用最能描述响应形状的术语。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3163485|如果你所有的资源都是顶级的，那么你可以使用单一的表示。避免拐点是一个巨大的胜利。|3163486|如果您正在执行任何类型的深度链接来表示关系上的查询，那么针对您的API编写的开发人员可以通过具有更严格的约定来获得帮助。|3163487|我的惯例是，URI中的每个深度级别都描述了与父资源的交互，完整的URI应该隐式地描述正在检索的内容。|3163488|假设我们有以下模型。|3163489|interface+User+{
++++<string>id;
++++<Friend[]>friends;
++++<Manager>user;
}

interface+Friend+{
++++<string>id;
++++<User>user;
++++...<<friendship+specific+props>>
}|code-block|syntax|javascript|3163490|如果我需要提供一个资源，允许客户端获取特定用户的特定朋友的经理，它可能如下所示：|3163491|GET+/users/{id}/friends/{friendId}/manager|offset|length|style|CODE|3163492|下面是更多的例子：|3163493|3163494|GET+/users+-列出全局用户中的用户资源collection|unordered-list-item|3163495|POST+/users+-在全局用户中创建新用户collection|3163496|GET+/users/{id}+-从全局用户中检索特定用户collection|3163497|GET+/users/{id}/manager+-获取特定user|3163498|GET+/users/{id}/friends的经理-获取user|3163499|GET+/users/{id}/friends/{friendId}的好友列表-获取某个user|3163500|LINK+/users/{id}/friends的特定好友-将好友关联添加到此user|3163501|UNLINK+/users/{id}/friends+-从此用户移除好友关联|3163502|3163503|请注意，每个级别如何映射到可执行操作的父级。对同一对象使用不同的父对象是违反直觉的。在GET+/resource/123上检索资源时，不会留下应该在POST+/resources上创建新资源的指示|3163504|entityMap^0|0|0|0|0|0|0|0|0|16|0|0|0|0|A|0|0|B|0|0|F|0|0|N|0|0|N|0|0|Y|0|0|O|0|0|Q|0|0|17|H|22|F|0^^$0|@$1|2|3|4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1P|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|1Q|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|1R|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1S|8|@$S|1T|T|1U|U|V]]|9|@]|A|$]]|$1|W|3|X|5|6|7|1V|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]|$1|Z|3|10|5|11|7|1X|8|@$S|1Y|T|1Z|U|V]]|9|@]|A|$]]|$1|12|3|13|5|11|7|20|8|@$S|21|T|22|U|V]]|9|@]|A|$]]|$1|14|3|15|5|11|7|23|8|@$S|24|T|25|U|V]]|9|@]|A|$]]|$1|16|3|17|5|11|7|26|8|@$S|27|T|28|U|V]]|9|@]|A|$]]|$1|18|3|19|5|11|7|29|8|@$S|2A|T|2B|U|V]]|9|@]|A|$]]|$1|1A|3|1B|5|11|7|2C|8|@$S|2D|T|2E|U|V]]|9|@]|A|$]]|$1|1C|3|1D|5|11|7|2F|8|@$S|2G|T|2H|U|V]]|9|@]|A|$]]|$1|1E|3|1F|5|11|7|2I|8|@$S|2J|T|2K|U|V]]|9|@]|A|$]]|$1|1G|3|-4|5|6|7|2L|8|@]|9|@]|A|$]]|$1|1H|3|1I|5|6|7|2M|8|@$S|2N|T|2O|U|V]|$S|2P|T|2Q|U|V]]|9|@]|A|$]]|$1|1J|3|-4|5|6|7|2R|8|@]|9|@]|A|$]]]|1K|$]]

Both representations are useful. I had used singular for convenience for quite some time, inflection can be difficult. My experience in developing strictly singular REST APIs, the developers consuming the endpoint lack certainty in what the shape of the result may be. I now prefer to use the term that best describes the shape of the response.

If all of your resources are top level, then you can get away with singular representations. Avoiding inflection is a big win.

If you are doing any sort of deep linking to represent queries on relations, then developers writing against your API can be aided by having a stricter convention.

My convention is that each level of depth in a URI is describing an interaction with the parent resource, and the full URI should implicitly describe what is being retrieved.

Suppose we have the following model.

<pre><code>interface User {
 &lt;string&gt;id;
 &lt;Friend[]&gt;friends;
 &lt;Manager&gt;user;
}

interface Friend {
 &lt;string&gt;id;
 &lt;User&gt;user;
 ...&lt;&lt;friendship specific props&gt;&gt;
}
</code></pre>

If I needed to provide a resource that allows a client to get the manager of a particular friend of a particular user, it might look something like:

<code>GET /users/{id}/friends/{friendId}/manager</code>

The following are some more examples:

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

Notice how each level maps to a parent that can be acted upon. Using different parents for the same object is counterintuitive. Retrieving a resource at <code>GET /resource/123</code> leaves no indication that creating a new resource should be done at <code>POST /resources</code>

blocks|key|257952|text|我更喜欢使用复数(/resources)和单数(/resource/{id})，因为我认为它更清楚地区分了处理资源集合和处理单个资源之间的逻辑。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|257953|作为一个重要的副作用，它还可以帮助防止有人错误地使用API。例如，假设用户错误地尝试通过将Id指定为参数来获取资源，如下所示：|257954|GET+/resources?Id=123|code-block|syntax|javascript|257955|在这种情况下，我们使用复数版本，服务器很可能会忽略Id参数并返回所有资源的列表。如果用户不小心，他会认为调用成功，并使用列表中的第一个资源。|257956|另一方面，当使用单数形式时：|257957|GET+/resource?Id=123|257958|服务器很可能会返回一个错误，因为Id没有以正确的方式指定，并且用户必须意识到有些地方是错误的。|257959|entityMap^0|9|A|O|E|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]|$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|11|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|12|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|13|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|14|8|@]|D|@]|E|$]]|$1|Q|3|R|5|J|7|15|8|@]|D|@]|E|$K|L]]|$1|S|3|T|5|6|7|16|8|@]|D|@]|E|$]]|$1|U|3|-4|5|6|7|17|8|@]|D|@]|E|$]]]|V|$]]

I prefer to use both plural (<code>/resources</code>) and singular (<code>/resource/{id}</code>) because I think that it more clearly separates the logic between working on the collection of resources and working on a single resource.

As an important side-effect of this, it can also help to prevent somebody using the API wrongly. For example, consider the case where a user wrongly tries to get a resource by specifying the Id as a parameter like this: 

<pre><code>GET /resources?Id=123
</code></pre>

In this case, where we use the plural version, the server will most likely ignore the Id parameter and return the list of all resources. If the user is not careful, he will think that the call was successful and use the first resource in the list. 

On the other hand, when using the singular form: 

<pre><code>GET /resource?Id=123
</code></pre>

the server will most likely return an error because the Id is not specified in the right way, and the user will have to realize that something is wrong.

blocks|key|2949614|text|我知道大多数人在选择使用复数还是单数之间左右为难。这里没有解决的问题是，客户将需要知道您使用的是哪一个，并且他们总是可能出错。这就是我的建议的来源。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2949615|，我的意思是对你的整个使用单数，然后创建路由，将复数形式的请求转发到单数形式。例如：|offset|length|style|BOLD|2949616|GET++/resources+++++=+++++GET++/resource
GET++/resources/1+++=+++++GET++/resource/1
POST+/resources/1+++=+++++POST+/resource/1
...|code-block|syntax|javascript|2949617|你就明白了。没有人是错的，只需最少的努力，客户总是会做对的。|2949618|entityMap^0|0|B|V|0|0|0|U|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@$D|S|E|T|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|U|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|V|8|@$D|W|E|X|F|G]]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|P|$]]

I know most people are between deciding whether to use plural or singular. The issue that has not been addressed here is that the client will need to know which one you are using, and they are always likely to make a mistake. This is where my suggestion comes from. 

How about both? And by that, I mean use singular for your whole API and then create routes to forward requests made in the plural form to the singular form. For example:

<pre><code>GET /resources = GET /resource
GET /resources/1 = GET /resource/1
POST /resources/1 = POST /resource/1
...
</code></pre>

You get the picture. No one is wrong, minimal effort, and the client will always get it right.

blocks|key|260130|text|这样如何：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|260131|/resource/+(非/resource)|offset|length|style|CODE|260132|/resource/意味着它是一个包含“资源”的文件夹，它是一个“资源”文件夹。|260133|我还认为数据库表的命名约定是相同的，例如，一个名为"user“的表就是一个"user+table"，它包含一个叫做”user“的东西。|260134|entityMap^0|0|0|A|D|9|0|0|A|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@$D|P|E|Q|F|G]|$D|R|E|S|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@$D|U|E|V|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|M|$]]

How about:

<code>/resource/</code> (not <code>/resource</code>)

<code>/resource/</code> means it's a folder contains something called "resource", it's a "resouce" folder.

And also I think the naming convention of database tables is the same, for example, a table called 'user' is a "user table", it contains something called "user".

blocks|key|261992|text|应该将路由中的id视为列表的索引，并且应该相应地进行命名。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|261993|numbers+=+[1,+2,+3]

numbers++++++++++++GET+/numbers
numbers[1]+++++++++GET+/numbers/1
numbers.push(4)++++POST+/numbers
numbers[1]+=+23++++PUT+/numbers/1|code-block|syntax|javascript|261994|但有些资源在路由中不使用in，因为要么只有一个in，要么用户永远不能访问多个in，所以这些不是列表：|261995|GET+/dashboard
DELETE+/session
POST+/login
GET+/users/{:id}/profile
PUT+/users/{:id}/profile|261996|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

An id in a route should be viewed the same as an index to a list, and naming should proceed accordingly.
<pre><code>numbers = [1, 2, 3]

numbers GET /numbers
numbers[1] GET /numbers/1
numbers.push(4) POST /numbers
numbers[1] = 23 PUT /numbers/1
</code></pre>
But some resources don't use ids in their routes because there's either only one, or a user never has access to more than one, so those aren't lists:
<pre><code>GET /dashboard
DELETE /session
POST /login
GET /users/{:id}/profile
PUT /users/{:id}/profile
</code></pre>

blocks|key|257988|text|有关命名资源的另一种说法，请参阅谷歌的API+Design+Guide:+Resource+Names。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|257989|本指南要求集合使用复数命名。|257990|%7C--------------------------%2B---------------%2B-------------------%2B---------------%2B--------------%7C
%7C+API+Service+Name+++++++++%7C+Collection+ID+%7C+Resource+ID+++++++%7C+Collection+ID+%7C+Resource+ID++%7C
%7C--------------------------%2B---------------%2B-------------------%2B---------------%2B--------------%7C
%7C+//mail.googleapis.com++++%7C+/users++++++++%7C+/name@example.com+%7C+/settings+++++%7C+/customFrom++%7C
%7C+//storage.googleapis.com+%7C+/buckets++++++%7C+/bucket-id++++++++%7C+/objects++++++%7C+/object-id+++%7C
%7C--------------------------%2B---------------%2B-------------------%2B---------------%2B--------------%7C|code-block|syntax|javascript|257991|如果你正在思考这个话题，这本书值得一读。|257992|entityMap|0|LINK|mutability|MUTABLE|url|https://cloud.google.com/apis/design/resource_names^0|J|W|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@$A|V|B|W|1|X]]|C|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|Z|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|10|8|@]|9|@]|C|$]]|$1|M|3|-4|5|6|7|11|8|@]|9|@]|C|$]]]|N|$O|$5|P|Q|R|C|$S|T]]]]

See Google's <a href="https://cloud.google.com/apis/design/resource_names" rel="nofollow noreferrer">API Design Guide: Resource Names</a> for another take on naming resources.
The guide requires collections to be named with plurals.
<pre><code>|--------------------------+---------------+-------------------+---------------+--------------|
| API Service Name | Collection ID | Resource ID | Collection ID | Resource ID |
|--------------------------+---------------+-------------------+---------------+--------------|
| //mail.googleapis.com | /users | /name@example.com | /settings | /customFrom |
| //storage.googleapis.com | /buckets | /bucket-id | /objects | /object-id |
|--------------------------+---------------+-------------------+---------------+--------------|
</code></pre>
It's worthwhile reading if you're thinking about this subject.

blocks|key|3163618|text|我不喜欢看到id的{id}部分与子资源重叠，因为理论上URL可以是任何东西，并且会有歧义。它混合了不同的概念(标识符和子资源名称)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3163619|类似的问题经常出现在enum常量或文件夹结构中，其中混合了不同的概念(例如，当您有文件夹Tigers、Lions和Cheetahs，然后在同一级别上还有一个名为Animals的文件夹时-这没有任何意义，因为其中一个是另一个的子集)。|3163620|一般来说，我认为端点的最后命名部分应该是单数的，如果它一次处理一个实体，则应该是复数；如果它处理的是一系列实体，则应该是复数。|3163621|因此，处理单个用户的端点：|3163622|GET++/user+++++++++++++->+Not+allowed,+400
GET++/user/{id}++++++++->+Returns+user+with+given+id
POST+/user+++++++++++++->+Creates+a+new+user
PUT++/user/{id}++++++++->+Updates+user+with+given+id
DELETE+/user/{id}++++++->+Deletes+user+with+given+id|code-block|syntax|javascript|3163623|然后有单独的资源用于对用户进行查询，通常会返回一个列表：|3163624|GET+/users+++++++++++++->+Lists+all+users,+optionally+filtered+by+way+of+parameters
GET+/users/new?since=x+->+Gets+all+users+that+are+new+since+a+specific+time
GET+/users/top?max=x+++->+Gets+top+X+active+users|3163625|下面是一些处理特定用户的子资源的示例：|3163626|GET+/user/{id}/friends+->+Returns+a+list+of+friends+of+given+user|3163627|交一个朋友(多对多链接)：|3163628|PUT+/user/{id}/friend/{id}+++++->+Befriends+two+users
DELETE+/user/{id}/friend/{id}++->+Unfriends+two+users
GET+/user/{id}/friend/{id}+++++->+Gets+status+of+friendship+between+two+users|3163629|永远不会有任何歧义，资源的复数或单数命名是对用户的提示，他们可以期待什么(列表或对象)。对id没有限制，理论上可以使用id为new的用户，而不会与(未来可能的)子资源名称重叠。|3163630|entityMap^0|6|2|9|4|0|A|4|18|6|1F|5|1L|8|28|7|0|0|0|0|0|0|0|0|0|0|19|2|1Q|3|0^^$0|@$1|2|3|4|5|6|7|16|8|@$9|17|A|18|B|C]|$9|19|A|1A|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1B|8|@$9|1C|A|1D|B|C]|$9|1E|A|1F|B|C]|$9|1G|A|1H|B|C]|$9|1I|A|1J|B|C]|$9|1K|A|1L|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1M|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|1N|8|@]|D|@]|E|$]]|$1|L|3|M|5|N|7|1O|8|@]|D|@]|E|$O|P]]|$1|Q|3|R|5|6|7|1P|8|@]|D|@]|E|$]]|$1|S|3|T|5|N|7|1Q|8|@]|D|@]|E|$O|P]]|$1|U|3|V|5|6|7|1R|8|@]|D|@]|E|$]]|$1|W|3|X|5|N|7|1S|8|@]|D|@]|E|$O|P]]|$1|Y|3|Z|5|6|7|1T|8|@]|D|@]|E|$]]|$1|10|3|11|5|N|7|1U|8|@]|D|@]|E|$O|P]]|$1|12|3|13|5|6|7|1V|8|@$9|1W|A|1X|B|C]|$9|1Y|A|1Z|B|C]]|D|@]|E|$]]|$1|14|3|-4|5|6|7|20|8|@]|D|@]|E|$]]]|15|$]]

I don't like to see the <code>{id}</code> part of the URLs overlap with sub-resources, as an <code>id</code> could theoretically be anything and there would be ambiguity. It is mixing different concepts (identifiers and sub-resource names). 

Similar issues are often seen in <code>enum</code> constants or folder structures, where different concepts are mixed (for example, when you have folders <code>Tigers</code>, <code>Lions</code> and <code>Cheetahs</code>, and then also a folder called <code>Animals</code> at the same level -- this makes no sense as one is a subset of the other).

In general I think the last named part of an endpoint should be singular if it deals with a single entity at a time, and plural if it deals with a list of entities.

So endpoints that deal with a single user:

<pre><code>GET /user -&gt; Not allowed, 400
GET /user/{id} -&gt; Returns user with given id
POST /user -&gt; Creates a new user
PUT /user/{id} -&gt; Updates user with given id
DELETE /user/{id} -&gt; Deletes user with given id
</code></pre>

Then there is separate resource for doing queries on users, which generally return a list:

<pre><code>GET /users -&gt; Lists all users, optionally filtered by way of parameters
GET /users/new?since=x -&gt; Gets all users that are new since a specific time
GET /users/top?max=x -&gt; Gets top X active users
</code></pre>

And here some examples of a sub-resource that deals with a specific user:

<pre><code>GET /user/{id}/friends -&gt; Returns a list of friends of given user
</code></pre>

Make a friend (many to many link):

<pre><code>PUT /user/{id}/friend/{id} -&gt; Befriends two users
DELETE /user/{id}/friend/{id} -&gt; Unfriends two users
GET /user/{id}/friend/{id} -&gt; Gets status of friendship between two users
</code></pre>

There is never any ambiguity, and the plural or singular naming of the resource is a hint to the user what they can expect (list or object). There are no restrictions on <code>id</code>s, theoretically making it possible to have a user with the id <code>new</code> without overlapping with a (potential future) sub-resource name.

blocks|key|2949779|text|使用单数，并利用英语中的惯例，例如“商业目录”。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2949780|很多东西都是这样读的：“书盒”、“狗狗包”、“美术馆”、“电影节”、“停车场”等等。|2949781|这可以方便地从左到右匹配url路径。左侧的项目类型。将文字设置在右侧。|2949782|GET+/users真的会吸引一组用户吗？通常不会。它获取一组存根，其中可能包含一个键和一个用户名。所以这不是真正的/users。它是用户的索引，或者是“用户索引”。为什么不这么说呢？这是个/user/index。因为我们已经命名了集合类型，所以我们可以有多个类型来显示用户的不同投影，而不需要求助于查询参数，例如user/phone-list或/user/mailing-list。|offset|length|style|CODE|2949783|那么用户300呢？仍然是/user/300。|2949784|GET+/user/index
GET+/user/{id}

POST+/user
PUT+/user/{id}

DELETE+/user/{id}|code-block|syntax|javascript|2949785|最后，HTTP对单个请求只能有一个响应。路径总是指单数形式的东西。|2949786|entityMap^0|0|0|0|0|A|1M|6|2N|B|4D|F|4T|I|0|C|9|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Z|8|@$H|10|I|11|J|K]|$H|12|I|13|J|K]|$H|14|I|15|J|K]|$H|16|I|17|J|K]|$H|18|I|19|J|K]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1A|8|@$H|1B|I|1C|J|K]]|9|@]|A|$]]|$1|N|3|O|5|P|7|1D|8|@]|9|@]|A|$Q|R]]|$1|S|3|T|5|6|7|1E|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]]|V|$]]

Use Singular and take advantage of the English convention seen in e.g. "Business Directory".

Lots of things read this way: "Book Case", "Dog Pack", "Art Gallery", "Film Festival", "Car Lot", etc.

This conveniently matches the url path left to right. Item type on the left. Set type on the right.

Does <code>GET /users</code> really ever fetch a set of users? Not usually. It fetches a set of stubs containing a key and perhaps a username. So it's not really <code>/users</code> anyway. It's an index of users, or a "user index" if you will. Why not call it that? It's a <code>/user/index</code>. Since we've named the set type, we can have multiple types showing different projections of a user without resorting to query parameters e.g. <code>user/phone-list</code> or <code>/user/mailing-list</code>.

And what about User 300? It's still <code>/user/300</code>.

<pre><code>GET /user/index
GET /user/{id}

POST /user
PUT /user/{id}

DELETE /user/{id}
</code></pre>

In closing, HTTP can only ever have a single response to a single request. A path is always referring to a singular something.

blocks|key|2949970|text|最重要的是|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2949971|/pants，/eye-glasses+-这些是单数路径还是复数路径？|offset|length|style|CODE|2949972|/radii+-您是否知道它的单一路径是/radius还是/radix|2949973|/index+-你知道它的复数路径是/indexes、/indeces还是/indices吗|2949974|任何时候，当你在接口和代码中使用复数时，问问你自己，你的约定是如何处理上面这样的单词的？|2949975|理想情况下，约定应该在没有不规则的情况下进行扩展。英语复数不能做到这一点，因为|2949976|2949977|他们有一些例外，比如某个事物被复数形式称为复数形式，|ordered-list-item|2949978|没有简单的算法可以从单数形式中获得单词的复数形式，从复数形式中获得单数形式，或者区分一个未知名词是单数形式还是复数形式。|2949979|2949980|这也有不利的一面。我脑海中最突出的几个：|2949981|2949982|单数形式和复数形式相同的名词将强制您的代码处理“复数”端点和“单数”端点具有相同路径的情况。|2949983|您的用户/开发人员必须精通英语，知道名词的正确单数和复数。在日益国际化的世界里，这可能会造成不可忽视的挫折和开销。|2949984|It单枪匹马地转向"I+know+/foo/{{id}}，what's+path+to+get+all+foo?“解决自然语言问题，而不是“去掉最后一条路径”的问题。|2949985|2949986|同时，一些人类语言甚至没有名词的单复数形式。他们管理得很好。你的API也可以。|2949987|entityMap^0|0|0|6|7|C|0|0|6|K|7|T|6|0|0|6|I|8|R|8|11|8|0|0|0|0|0|0|0|0|0|0|0|H|B|1G|3|0|0|0^^$0|@$1|2|3|4|5|6|7|1A|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1B|8|@$D|1C|E|1D|F|G]|$D|1E|E|1F|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1G|8|@$D|1H|E|1I|F|G]|$D|1J|E|1K|F|G]|$D|1L|E|1M|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1N|8|@$D|1O|E|1P|F|G]|$D|1Q|E|1R|F|G]|$D|1S|E|1T|F|G]|$D|1U|E|1V|F|G]]|9|@]|A|$]]|$1|L|3|M|5|6|7|1W|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1X|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|Q|3|R|5|S|7|1Z|8|@]|9|@]|A|$]]|$1|T|3|U|5|S|7|20|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|21|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|22|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|23|8|@]|9|@]|A|$]]|$1|Z|3|10|5|S|7|24|8|@]|9|@]|A|$]]|$1|11|3|12|5|S|7|25|8|@]|9|@]|A|$]]|$1|13|3|14|5|S|7|26|8|@$D|27|E|28|F|G]|$D|29|E|2A|F|G]]|9|@]|A|$]]|$1|15|3|-4|5|6|7|2B|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|2C|8|@]|9|@]|A|$]]|$1|18|3|-4|5|6|7|2D|8|@]|9|@]|A|$]]]|19|$]]

<h1>The Most Important Thing</h1>
<code>/pants</code>, <code>/eye-glasses</code> - are those the singular or the plural path?
<code>/radii</code> - do you know off the top of your head if the singular path for that is <code>/radius</code> or <code>/radix</code>?
<code>/index</code> - do you know off the top of your head if plural path for that is <code>/indexes</code> or <code>/indeces</code> or <code>/indices</code>?
Any time you are using plurals in interfaces and code, ask yourself, how does your convention handle words like the above?
Conventions should ideally scale without irregularity. English plurals do not do this, because
<ol>
<li>they have exceptions like one of something being called by the plural form, and</li>
<li>there is no trivial algorithm to get the plural of a word from the singular, get the singular from the plural, or tell if an unknown noun is singular or plural.</li>
</ol>
This has downsides. The most prominent ones off the top of my head:
<ol>
<li>The nouns whose singular and plural forms are the same will force your code to handle the case where the &quot;plural&quot; endpoint and the &quot;singular&quot; endpoint have the same path anyway.</li>
<li>Your users/developers have to be proficient with English enough to know the correct singulars and plurals for nouns. In an increasingly internationalized world, this can cause non-negligible frustration and overhead.</li>
<li>It singlehandedly turns &quot;I know <code>/foo/{{id}}</code>, what's the path to get all <code>foo</code>?&quot; into a natural language problem instead of a &quot;just drop the last path part&quot; problem.</li>
</ol>
Meanwhile, some human languages don't even have different singular and plural forms for nouns. They manage just fine. So can your API.

blocks|key|2950061|text|这是罗伊·菲尔丁关于"Architectural+Styles+and+the+Design+of+Network-based+Software+Architectures“的论文，你可能会对这句话感兴趣：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2950062|2950063|资源是到一组实体的概念映射，而不是在任何特定时间点对应于映射的实体。|blockquote|2950064|2950065|2950066|作为一种资源，一种映射到一组实体的映射，在我看来，使用/product/而不是/products/本身作为访问一组产品的资源似乎不符合逻辑。如果你需要一个特定的产品，那么你可以访问/product/1/。|style|CODE|2950067|作为进一步的参考，此来源有一些关于资源命名约定的单词和示例：|2950068|2950069|https://restfulapi.net/resource-naming/|unordered-list-item|2950070|2950071|entityMap|0|LINK|mutability|MUTABLE|url|https://www.ics.uci.edu/%257Efielding/pubs/dissertation/fielding_dissertation.pdf|1^0|B|23|0|0|0|0|0|0|R|9|13|A|2I|B|0|0|0|0|13|1|0|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@$A|14|B|15|1|16]]|C|$]]|$1|D|3|-4|5|6|7|17|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|18|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|19|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|1A|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|1B|8|@$A|1C|B|1D|L|M]|$A|1E|B|1F|L|M]|$A|1G|B|1H|L|M]]|9|@]|C|$]]|$1|N|3|O|5|6|7|1I|8|@]|9|@]|C|$]]|$1|P|3|-4|5|6|7|1J|8|@]|9|@]|C|$]]|$1|Q|3|R|5|S|7|1K|8|@]|9|@$A|1L|B|1M|1|1N]]|C|$]]|$1|T|3|-4|5|6|7|1O|8|@]|9|@]|C|$]]|$1|U|3|-4|5|6|7|1P|8|@]|9|@]|C|$]]]|V|$W|$5|X|Y|Z|C|$10|11]]|12|$5|X|Y|Z|C|$10|R]]]]

Here's Roy Fielding dissertation of &quot;<a href="https://www.ics.uci.edu/%7Efielding/pubs/dissertation/fielding_dissertation.pdf" rel="nofollow noreferrer">Architectural Styles and the Design of Network-based Software Architectures</a>&quot;, and this quote might be of your interest:
<blockquote>
A resource is a conceptual mapping
to a set of entities, not the entity that corresponds to the mapping at any particular point in
time.
</blockquote>
Being a resource, a mapping to a set of entities, doesn't seem logical to me, to use <code>/product/</code> as resource for accessing set of products, rather than <code>/products/</code> itself. And if you need a particular product, then you access <code>/product/1/</code>.
As a further reference, this source has some words and examples on resource naming convention:
<ul>
<li><a href="https://restfulapi.net/resource-naming/" rel="nofollow noreferrer">https://restfulapi.net/resource-naming/</a></li>
</ul>

blocks|key|2950184|text|关于这个问题的很好的讨论点。在我的经验中，命名约定或者更确切地说没有建立本地标准是许多长夜待命、头痛、危险的重构、不可靠的部署、代码审查辩论等的根本原因，等等。特别是当它决定事情需要改变时，因为一开始没有充分考虑。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2950185|一个实际问题跟踪了关于这一点的讨论：|2950186|https://github.com/kubernetes/kubernetes/issues/18622|offset|length|2950187|看到这方面的分歧是很有趣的。|2950188|我的两点意见(有一点令人头疼的经验)是，当你考虑像用户、post、订单、文档等常见实体时，你应该始终将它们作为实际实体来处理，因为这是数据模型所基于的。语法和模型实体不应该在这里混为一谈，这会造成其他方面的混淆。然而，一切都是黑白分明的吗？确实很少这样。上下文确实很重要。|2950189|当您希望获取系统中的用户集合时，例如：|2950190|获取实体用户的/user+->集合|style|CODE|2950191|获取实体用户的/user/1+->资源:1|2950192|既可以说我想要一个实体用户集合，也可以说我想要用户集合。|2950193|获取实体用户的/users+->集合|2950194|获取实体用户的/users/1+->资源:1|2950195|从这里可以看出，从用户集合中，给我用户/1。|2950196|但是如果你分解用户集合是什么.它是实体的集合吗?其中每个实体都是一个User实体。|2950197|您不会说entity是Users，因为单个数据库表通常是User的单个记录。但是，我们在这里讨论的是RESTful服务，而不是数据库ERM。|2950198|但这只适用于有明确名词区分的用户，而且很容易掌握。然而，当你在一个系统中有多个相互冲突的方法时，事情会变得非常复杂。|2950199|老实说，除了少数情况下英语只是意大利面条之外，这两种方法在大多数情况下都是有意义的。它似乎是一种迫使我们做出许多决定的语言！|2950200|2950201|这个问题的简单事实是，无论你做什么决定，都要在你的意图中保持一致和合乎逻辑。|blockquote|BOLD|2950202|2950203|2950204|在我看来，这里和那里的混合是一个糟糕的方法！这悄悄地引入了一些可以完全避免的语义歧义。|2950205|看似奇特的偏好：|2950206|https://www.haproxy.com/blog/using-haproxy-as-an-api-gateway-part-1/|2950207|类似的讨论思路如下：|2950208|https://softwareengineering.stackexchange.com/questions/245202/what-is-the-argument-for-singular-nouns-in-restful-api-resource-naming|2950209|这里最重要的常量是，它确实似乎确实下降到一定程度的团队/公司文化偏好，根据在更大的公司指南中找到的详细信息，这两种方式都有许多利弊。谷歌不一定是对的，仅仅因为它是谷歌！这一点适用于任何指导方针。|2950210|避免把你的头埋在沙子里太多，并且松散地建立你对轶事例子和观点的整个理解系统。|2950211|你必须为每件事建立坚实的推理。如果它适合你，或者你的团队和/我们的客户，并且对新的和经验丰富的开发人员有意义(如果你在团队环境中)，很好。|2950212|entityMap|0|LINK|mutability|MUTABLE|url|1|2^0|0|0|0|1H|0|0|0|0|0|7|5|0|7|7|0|0|7|6|0|7|8|0|J|2|0|Y|4|0|B|5|S|4|0|0|0|0|K|7|0|0|0|0|0|0|1W|1|0|0|0|3P|2|0|0|0|0^^$0|@$1|2|3|4|5|6|7|25|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|26|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|27|8|@]|9|@$F|28|G|29|1|2A]]|A|$]]|$1|H|3|I|5|6|7|2B|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|2C|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|2D|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|2E|8|@$F|2F|G|2G|P|Q]]|9|@]|A|$]]|$1|R|3|S|5|6|7|2H|8|@$F|2I|G|2J|P|Q]]|9|@]|A|$]]|$1|T|3|U|5|6|7|2K|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|2L|8|@$F|2M|G|2N|P|Q]]|9|@]|A|$]]|$1|X|3|Y|5|6|7|2O|8|@$F|2P|G|2Q|P|Q]]|9|@]|A|$]]|$1|Z|3|10|5|6|7|2R|8|@$F|2S|G|2T|P|Q]]|9|@]|A|$]]|$1|11|3|12|5|6|7|2U|8|@$F|2V|G|2W|P|Q]]|9|@]|A|$]]|$1|13|3|14|5|6|7|2X|8|@$F|2Y|G|2Z|P|Q]|$F|30|G|31|P|Q]]|9|@]|A|$]]|$1|15|3|16|5|6|7|32|8|@]|9|@]|A|$]]|$1|17|3|18|5|6|7|33|8|@]|9|@]|A|$]]|$1|19|3|-4|5|6|7|34|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|1C|7|35|8|@$F|36|G|37|P|1D]]|9|@]|A|$]]|$1|1E|3|-4|5|6|7|38|8|@]|9|@]|A|$]]|$1|1F|3|-4|5|6|7|39|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|3A|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|6|7|3B|8|@]|9|@]|A|$]]|$1|1K|3|1L|5|6|7|3C|8|@]|9|@$F|3D|G|3E|1|3F]]|A|$]]|$1|1M|3|1N|5|6|7|3G|8|@]|9|@]|A|$]]|$1|1O|3|1P|5|6|7|3H|8|@]|9|@$F|3I|G|3J|1|3K]]|A|$]]|$1|1Q|3|1R|5|6|7|3L|8|@]|9|@]|A|$]]|$1|1S|3|1T|5|6|7|3M|8|@]|9|@]|A|$]]|$1|1U|3|1V|5|6|7|3N|8|@]|9|@]|A|$]]|$1|1W|3|-4|5|6|7|3O|8|@]|9|@]|A|$]]]|1X|$1Y|$5|1Z|20|21|A|$22|E]]|23|$5|1Z|20|21|A|$22|1L]]|24|$5|1Z|20|21|A|$22|1P]]]]

Great discussion points on this matter. Naming conventions or rather not establishing local standards has been in my experience the root cause of many long nights on-call, headaches, risky refactoring, dodgy deployments, code review debates, etc, etc, etc. Particularly when its decided that things need to change because insufficient consideration was given at the start.
An actual issue tracked discussion on this:
<a href="https://github.com/kubernetes/kubernetes/issues/18622" rel="nofollow noreferrer">https://github.com/kubernetes/kubernetes/issues/18622</a>
It is interesting to see the divide on this.
My two cents (with a light seasoning of headache experience) is that when you consider common entities like a user, post, order, document etc. you should always address them as the actual entity since that is what a data model is based on. Grammar and model entities shouldn't really be mixed up here and this will cause other points of confusion. However, is everything always black and white? Rarely so indeed. Context really matters.
When you wish to get a collection of users in a system, for example:
GET <code>/user</code> -&gt; Collection of entity User
GET <code>/user/1</code> -&gt; Resource of entity User:1
It is both valid to say I want a collection of entity user and to say I want the users collection.
GET <code>/users</code> -&gt; Collection of entity User
GET <code>/users/1</code> -&gt; Resource of entity User:1
From this you are saying, from the collection of users, give me user <code>/1</code>.
But if you break down what a collection of users is... Is it a collection of entities where each entity is a <code>User</code> entity.
You would not say entity is <code>Users</code> since a single database table is typically an individual record for a <code>User</code>. However, we are talking about a RESTful service here not a database ERM.
But this is only for a User with clear noun distinction and is an easy one to grasp. Things get very complex when you have multiple conflicting approaches in one system though.
Truthfully, either approach makes sense most of the time bar a few cases where English is just spaghetti. It appears to be a language that forces a number of decisions on us!
<blockquote>
The simple fact of the matter is that no matter what you decide, be consistent and logical in your intent.
</blockquote>
Just appears to me that mixing here and there is a bad approach! This quietly introduces some semantic ambiguity which can be totally avoided.
Seemingly singular preference:
<a href="https://www.haproxy.com/blog/using-haproxy-as-an-api-gateway-part-1/" rel="nofollow noreferrer">https://www.haproxy.com/blog/using-haproxy-as-an-api-gateway-part-1/</a>
Similar vein of discussion here:
<a href="https://softwareengineering.stackexchange.com/questions/245202/what-is-the-argument-for-singular-nouns-in-restful-api-resource-naming">https://softwareengineering.stackexchange.com/questions/245202/what-is-the-argument-for-singular-nouns-in-restful-api-resource-naming</a>
The overarching constant here is that it does indeed appear to be down to some degree of team/company cultural preferences with many pros and cons for both ways as per details found in the larger company guidelines. Google isn't necessarily right, just because it is Google! This holds true for any guidelines.
Avoid burying your head in the sand too much and loosely establishing your entire system of understanding on anecdotal examples and opinions.
Is it imperative that you establish solid reasoning for everything. If it scales for you, or your team and/our your customers and makes sense for new and seasoned devs (if you are in a team environment), nice one.

I'm new to REST and I've observed that in some RESTful services they use different resource URI for update/get/delete and Create. Such as

<ul>
<li>Create - using /resources with POST method (observe plural) at some places using /resource (singular)</li>
<li>Update - using /resource/123 with PUT method</li>
<li>Get - Using /resource/123 with GET method</li>
</ul>

I'm little bit confused about this URI naming convention. What should we use plural or singular for resource creation? What should be the criteria while deciding that?

REST URI convention - Singular or plural name of resource while creating it

软件开发

文件系统

数据库

服务器

路由

我是REST新手，我观察到在一些RESTful服务中，它们使用不同的资源URI来更新/获取/删除和创建。比如Create -在某些地方使用带POST方法的/resources (请观察复数)使用/resource Create-使用带PUT方法的/resource/123  GET -使用带有GET方法的我对这个URI...

问REST URI约定-创建资源时资源的单数或复数名称
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问REST URI约定-创建资源时资源的单数或复数名称EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问REST URI约定-创建资源时资源的单数或复数名称
EN