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