REST资源单数和复数是否合理？

我一直在想，而不是像这样更传统的布局：

api/Products
GET // gets product(s) by id
PUT // updates product(s) by id
DELETE // deletes (product(s) by id
POST // creates product(s)

具有单数和复数会更有用，例如：

api/Product
GET // gets a product by id
PUT // updates a product by id
DELETE // deletes a product by id
POST // creates a product

api/Products
GET // gets a collection of products by id
PUT // updates a collection of products by id
DELETE // deletes a collection of products (not the products themselves)
POST // creates a collection of products based on filter parameters passed

因此，要创建产品集合，您可以执行以下操作：

POST api/Products {data: filters} // returns api/Products/<id>

然后，要引用它，您可以这样做：

GET api/Products/<id> // returns array of products

在我看来，以这种方式做事的主要优点是可以轻松地缓存产品集合。例如，一个人可能花一小时的时间来收集产品，从而大大减少了服务器上的呼叫。当然，我目前只看到以这种方式做事的好处，这有什么坏处？

rest

— 伊娃
source

Answers:

通常，当集合将成为与api交互的最有用的方法时，将单个对象视为只有一个成员的集合会更简单。然后，如果以后要公开一个用于与单打交互的API，则只需在幕后将传入的单打转换为具有该成员的集合，然后使用其他API的相同实现即可。

我想我想说的是，如果您希望集合成为一种交互机制，请从仅集合API开始，在系统完成后，另一个API是接口层的简单辅助属性，则可以添加您会发现它特别有用。但是，您可能会发现它的用处很小，不足以应用YAGNI并仅将collections接口用于所需的一些单身实例。

— 吉米·霍法（Jimmy Hoffa）
source

虽然我同意您的观点，但是假设我们使用上面的示例，考虑到POST api / Products将用于传递集合过滤器参数，而不是用于创建新产品的数据，那么创建新产品的合理方法是没有api /产品？

— 伊娃（Eva）

@Evan为什么无法在api / Products中发布多个（或一个集合）产品？对我来说，这似乎是最合逻辑的。也许发布用于创建过滤器的产品/过滤器，或者获取它们（是检索任务而不是创建任务）。

— 吉米·霍法

谢谢您的精心安排，吉米。我不这样看的原因是，在上面的示例中，我正在考虑将集合作为自身的标识资源。在后端，api / Product可能是“ Product”，而api / Products可能是“ ProductCollection”。但是，经过一番考虑之后，我认为最好是像您的建议那样，从API中抽象出所有内容...现在是一个真正的问题，您是在去泰国的路上是从卡车停靠的地方开车还是离开了在汽车的后备箱中？

— 伊娃（Eva）2012年

@Evan，我给您两个提示：海鸥。

— 吉米·霍法

缺点是调用程序还必须对资源名称进行复数，对于那些没有内置复数机制的客户端语言来说，这可能很棘手。如果您将其保留为单数形式，则调用者可以更轻松地自动为其客户端库生成代码。

如果要减轻这种情况，可以自己为REST服务生成SDK。或者，您可以只是自以为是并处理投诉:)

— 克里斯·麦考尔
source