处理这些RESTful调用以处理状态的正确方法

Question

所以，我做了几个项目，在这些项目中调用项目的状态。通常是项目是启用还是喜欢或类似的东西。它必须是二元元素。

我通常说过这样做的正确方法是发布/删除，但更快的方法是做一些像

这样的事情

/api/toggle_enabled/23/item

或

/api/toggle_liked/28/item

并在服务器上协调状态并在响应中返回结果状态，如：

{
 id:23,
 is_enabled: true / false
}

或

{
 id:28,
 is_liked: true / false
}

通常其他开发人员呻吟（就像我一样）当我看到这一点但总是运行良好并简化了客户端代码，通过处理状态让用户很快多次按下按钮。其他开发人员如何处理这种情况，还有另一个很好的处理选择吗？我知道这打破了RESTful原则，但简单性似乎是值得的。

Answer 1

一切都取决于。因为REST是无状态的，所以这个问题出现并且在API的世界中非常普遍。

您处理此方案的方式通常适用，但我个人不喜欢它，我容忍它，因为它简单易行。您可以在下面找到处理此类案例的其他方案。

1. 如果您希望坚持使用REST规则，每次/api/item/28 liked设置/api/items/28/like|dislike时，您应该 PUT 所有实体。该请求应返回整个修改过的实体。
2. 如果您不希望每次 PATCH 都要发送整个实体。使用 PATCH 仅将已修改的字段与请求一起发送到同一端点。请注意，与 PUT 相比， PATCH 不是幂等的。此请求应返回整个实体或不返回任何内容。
3. 当更多高级方案发挥作用时（例如可能有多个喜欢） POST 肯定 应该用于例如增加喜欢数量或喜欢/不喜欢。请求应发送至/likes。为什么 POST ？由于这是资源上的操作 - 使用动词而不是名词。此类请求应返回已修改的实体以跟踪状态。
4. 这是3的扩展 - 不仅可以跟踪所有喜欢，还可以删除，评论等。在这种情况下，您将引入新资源：/likes和 POST new喜欢这个端点 - 作为回应，返回new like。如果需要提前过滤，请使用 GET 简单过滤/likes/filter集合或 POST varchar(max)。