我正在努力开发符合我的用例的RESTful最佳实践的API。
我的数据库模型看起来像：
公司：ID名称
位置：ID名称默认设置
LocationSettings：IDLocationId公司编号设置
在业务模型中，并非每个公司都设置位置值，因此在许多情况下，它将默认为位置中的值。如果用户决定更改该值，那么我们将存储其自定义设置，而不使用默认值。
我正在考虑以下方面的API：
GET / location-settings？companyId = id
GET / location-settings？companyId = id＆locationId = id
PUT / location-settings？companyId = id＆locationId = id
这个想法是，当用户决定更改任何设置时，我们将调用PUT路线-如果该公司存在自定义设置，它将更新位置设置，如果不存在，则在LocationSettings中创建一个新条目。] >
但是，这似乎是一种反模式，因为通常我看不到在PUT路由上以这种方式使用查询参数来指定要更新的资源。在这种情况下，我无法轻松提供位置设置资源的ID，因为它可能存在或可能不存在。我不想使用2条单独的路由（一条用于PUT，一条用于POST），因为在应用程序的用例中，这会造成混乱，即从最终用户的角度来看，默认设置逻辑是隐藏的，因此它们始终具有用于他们的公司，并只是对其进行更新。
我正在考虑的另一个选择是（选项2）：
GET / location-settings？companyId = id
GET / location-settings / locations / {locationId}？companyId = id
PUT / location-settings / locations / {locationId}？companyId = id
但是，这似乎很奇怪，因为位置不是位置设置的子资源。
我正在考虑的第三个选项是（选项3）：
获取/ locations / location-settings？companyId = id
GET / locations / {locationId} / location-settings？companyId = id
PUT / locations / {locationId} / location-settings？companyId = id
我个人最喜欢此选项。但是，我不确定像第一个get路由那样引用2个集合而没有ID是否是一种好的REST做法。
对此有何建议？
我正在努力开发符合我的用例的RESTful最佳实践的API。我的数据库模型如下所示：公司：ID名称位置：ID名称...
它[[声音
我看不到在PUT路由上以这种方式使用的查询参数来指定要更新的资源。