Question

我目前拥有一个非常标准的REST API服务：

show: GET /users/1
update: PUT /users/1

......以及一些遵循相同惯例的has_many关系：

show: GET /users/1/friends/1
update: PUT /users/1/friends/1

但是，还有一个EAV表来处理设置（抱歉，这部分不会改变），设置为充当has_one关系。内部：

user.settings # returns {:sound => true, :tutorials => true}
user.update_settings # expects {:sound => false}

它在本地运行良好，但没有ID可以像其他路线一样表示它。相反，路线可以设置如下：

show: GET /users/1/settings
update: PUT /users/1/settings

这是处理这种情况的正常方法吗，还是有其他一些我不知道的惯例？

Answer 1

那么，如果您不需要ID来访问设置，为什么不将其视为集合的属性？在内部，它与您相同，只需关闭/users/:id/settings端点即可。并GET和UPDATE用户资源更改设置。用户会看起来像这样：

{ "id" : 12,
 "settings": {
...
 }
}

如果您认为设置属性，则enpoint似乎在语法上不正确。想象一下，你提出了与用户年龄相同的问题。你会打开一个/ user /：id / age端点吗？这些设置是否具有更多属性？在哪里停下来？同样是概念问题，最重要的是一致性。

但不要成为一名REStafarian。你的方法也很好。对我而言，更多的是一致性问题，因此您不必为开发人员解释异常编写大量文档。因此，请考虑到最适合其他方面的选择（我会考虑我的建议）。

务实！