用于小动作的HTTP方法,例如(向上)投票

Question

动词对于CRUD动作非常简单.

什么是正确的HTTP动词只执行一个动作,像upvote？

也许这说明数据建模更多？是upvote资源还是仅属性？我对此不确定.假设它通过调用#upvote模型直接修改资源.

例如,如果我在SO上提出一个问题,那么该动作应该理想地使用什么动词？我正在以部分方式修改资源(PATCH？),但同时,我不想指定新值,因为我可能会遇到并发问题,因此最好由数据库管理.换句话说,我们要求服务器对资源执行增量操作.那是否涵盖PATCH？

我在那里看到过类似的问题,但他们的案例指出通过将作业请求视为要创建的对象来创建新资源.我们在这里是一样的吗？

如果PATCH方法真的合适,它会包含什么？

Answer 1

也许这说明数据建模更多？是upvote资源还是仅属性？

建模影响实施

我们通常在现实世界中对某些东西进行建模,我们选择的表示方式将严重影响开发系统的功能.我们可以通过两种方式实施我们的投票:作为被投票的事物的属性或作为一个实体本身的属性.选择将影响我们实现所需功能的容易程度.

两种可能的实施......

1.作为实体投票

我会用一个资源来模拟这一点,该资源模拟选民与被投票的事物之间的关系.为什么？

该票有状态:

• 什么被投票
• 谁投票,
• 什么时候投票.
• 这是一个投票或投票(你提到SO作为一个例子,所以我在这里包括这种可能性)

它本身就是一种资源,在投票中有着有趣的行为

• 保持正确的选票数
• 防止多次投票/投票

它可以使用REST轻松建模.

我可以POST/PUT新投票,删除之前的投票,用合格的GET查看我的投票.

系统可以确保我只投票一次 - 如果维护一个简单的计数器就不容易做到.

2.投票作为属性

在此实现中,我们将投票建模为计数器.在这种情况下,我们必须

1. 获取投票的整个状态 - 最大化客户端和服务器之间的接口

2. 更新柜台

3. 放回更新的状态 - 哎呀,有人已经同时更新了资源!

服务器现在没有简单的方法来处理来自同一个人的多个投票,而无需管理某些"侧面"状态.我们还有"丢失更新"问题.

事情很快变得复杂.

最后的建议

关于如何建模的决定应该由你需要系统做什么来决定.

通常没有正确的决定,只是努力和价值之间的最佳妥协.

选择最容易实现最常见用例的设计.常见的事情应该快速而简单,只需要可以实现不常见的事情.

克里斯