Question

我正在努力开发符合我的用例的RESTful最佳实践的API。

我的数据库模型看起来像：

公司： ID 名称

位置： ID 名称默认设置

LocationSettings： ID LocationId 公司编号设置

在业务模型中，并非每个公司都设置位置值，因此在许多情况下，它将默认为“位置”中的值。如果用户决定更改该值，那么我们将存储其自定义设置，而不使用默认值。

我一直在考虑以下方面的API：

获取/ location-settings？companyId = id

获取/ location-settings？companyId = id＆locationId = id

PUT / location-settings？companyId = id＆locationId = id

这个想法是，当用户决定更改任何设置时，我们将调用PUT路线-如果该公司存在自定义设置，它将更新位置设置，如果不存在，则将在LocationSettings中创建一个新条目。

但是，这似乎是一种反模式，因为通常我看不到在PUT路由上以这种方式使用的查询参数来指定要更新的资源。在这种情况下，我无法轻松地为位置设置资源提供ID，因为它可能存在也可能不存在。我不想使用2条单独的路由（一条用于PUT，一条用于POST），因为在应用程序的用例中，这会造成混乱，即从最终用户的角度来看，默认设置逻辑是隐藏的，因此它们始终具有用于他们的公司，并只是对其进行更新。

我想到的另一个选择是（选项2）：

获取/ location-settings？companyId = id

获取/ location-settings / locations / {locationId}？companyId = id

PUT / location-settings / locations / {locationId}？companyId = id

但是，这似乎很奇怪，因为位置不是位置设置的子资源。

我正在考虑的第三个选项是（选项3）：

获取/ locations / location-settings？companyId = id

获取/ locations / {locationId} / location-settings？companyId = id

PUT / locations / {locationId} / location-settings？companyId = id

我个人最喜欢此选项。但是，我不确定像第一个get路由那样引用2个集合而没有ID是否是一种好的REST做法。

对此有何建议？

Answer 1

听起来，就像每个公司只有一个“位置设置”一样。

如果是这样，那么您实际上不需要在网址中添加位置设置ID。

我可能错了，但看来您仅需要两条路线：

df['score']=df['answer'].str.split(', ').explode().isin(correct_list).groupby(level=0).sum()
print(df)
             answer  score
0  cats, dogs, pigs    2.0
1        cats, dogs    2.0
2        dogs, pigs    1.0
3              cats    1.0
4              pigs    0.0

Answer 2

我看不到在PUT路由上以这种方式使用的查询参数来指定要更新的资源。

是的，你不是。但是这样做是没有错的

PUT /x/y/z
PUT /x?y=z

这两个URI都是 fine ；通用组件将做正确的事情，URI模板很容易描述它们，依此类推。当然，它们之间需要权衡（HTML的便利性与相对引用的便利性）；但是如果以后发现要更改某些内容，则可以轻松地将其中一个重定向到另一个。

RESTful API，在PUT上查询参数

2 个答案: