Question

我的REST API格式：

@OneToOne(mappedBy = "reservationReminder", fetch = FetchType.LAZY)
@JsonIgnore
public Reservation getReservation() {
    return reservation;
}

此外，产品可以组织成产品组。

根据REST最佳实践获取所有产品组的正确方法是什么：

http://example.com/api/v1.0/products - get all products
http://example.com/api/v1.0/products/3 - get product with id=3

或

http://example.com/api/v1.0/products/groups

...

另一种选择？

Answer 1

如果您正在为您的客户开发Rest API，那么您不应该依赖于id。而是构建一个有意义的缩写，并将它们映射到服务器端的实际ID。

如果那是不可能的，而不是使用 http://example.com/api/v1.0/products/3您可以使用http://example.com/api/v1.0/products?product_id=3，然后您可以在文档中提供“product_id”说明。基本上告诉客户端使用product_id的方法。简而言之，一个url必须有意义并遵循一个模式。变量部分必须在url查询中发送（部分后？或POST有效负载）

有了这个，查询服务器的方法也很重要。如果客户端试图向服务器提供某些东西，他应该使用“GET”http请求，类似POST http请求，如果它正在上传新信息，“PUT”请求，如果它正在更新或创建新资源。

因此，通过这种类比http://example.com/api/v1.0/products/groups更合适，因为它遵循模式（产品中的组），而产品组更像是没有模式的关键字。

像模式这样的目录更容易理解。就像在文件系统（C：\ Program Files \ WinRAR）中一样，每个部分都会让我们得到更广泛的目标。

您还可以针对特定群组http://example.com/api/v1.0/products/groups?id=3

进行自定义

Answer 2

我不同意Rishabh Soni，因为http://example.com/api/v1.0/products/groups可能导致含糊不清。

我会把钱花在http://example.com/api/v1.0/productgroups上，甚至更好http://example.com/api/v1.0/product_groups（更好的可读性）。

我在这里有类似的讨论：Updating RESTful resources against aggregate roots only

问题：关于/ products / features或/ product-features的东西，   对此有何共识？你知道任何好的来源吗？   这不仅仅是品味问题吗？

答案：我认为这是误导。 我希望得到所有功能   在所有产品中而不是获得所有可能的功能。但是，是的   说实话，很难找到任何直接谈论此事的消息来源   问题，但有一堆文章，人们不会尝试   创建/ products / features之类的嵌套资源，但要这样做   separately

因此，我们无法确定http://example.com/api/v1.0/products/groups是否会返回所有可能的组或仅返回与所有现有产品相关联的所有组（那么尚未与该产品连接的组呢？）。

为避免这种歧义，您可以在文档中添加一些注释。但你可以准备http://example.com/api/v1.0/product_groups，一切都很清楚。

REST网址格式正确

2 个答案: