对于 CRUD 操作，动词非常简单。
什么是仅用于执行操作的正确 HTTP 动词，例如赞成票？
也许这更能说明数据建模？upvote 是一种资源还是一种属性？我不确定。假设它确实通过调用#upvote模型直接修改了资源。
例如，如果我在 SO 上提出一个问题，那么理想情况下应该使用哪个动词来完成该动作？我正在以部分方式（PATCH？）修改资源，但同时，我不想指定新值，因为我可能会遇到并发问题，因此最好由数据库管理。换句话说，我们想要求服务器对资源执行增量操作。被覆盖了PATCH吗？
我在那里看到了一个类似的问题，但他们的案例指向通过将作业请求视为要创建的对象来创建新资源。我们在这里是不是同样的情况？
如果该PATCH方法真的合适，它会包含什么？
也许这更能说明数据建模？upvote 是一种资源还是一种属性？
我们通常从现实世界中建模一些东西，我们选择的表示将严重影响开发系统的能力。我们可以通过两种方式实现我们的投票：作为被投票事物的属性或作为其自身的实体。选择将影响我们实现所需功能的难易程度。
我会用一个资源来模拟这个，这个资源模拟了选民和被投票的东西之间的关系。为什么？
投票有状态：
它本身就是一种资源，具有围绕选票的有趣行为
它可以使用 REST 轻松建模。
我可以 POST/PUT 一个新的投票，删除以前的投票，用合格的 GET 检查我的投票。
该系统可以确保我只投票一次——如果维护一个简单的计数器，这将不容易做到。
在这个实现中，我们将投票建模为计数器。在这种情况下，我们必须
获取被投票事物的整个状态——最大化客户端和服务器之间的接口
更新计数器
放回更新的状态 - 哎呀，同时有人已经更新了资源！
服务器现在没有简单的方法来处理来自同一个人的多张选票，而不需要“在一边”管理一些状态。我们也有“丢失更新”的问题。
事情很快变得复杂起来。
关于如何建模某物的决定应该由您需要系统做什么来决定。
往往没有正确的决定，只有努力与价值的最佳折衷。
选择最容易实现最常见用例的设计。常见的事情应该快速简单地完成，不常见的事情只需要可能。
克里斯