正确的方式来处理这些处理状态的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. 如果你想坚持到作息规律，你应该每次PUT所有的实体/api/item/28与liked设置正确。这个请求应该返回整个修改的实体。
2. 如果你不想每次发送整个实体PATCH是要走的路。使用修补程序只有修改的字段与请求一起发送到相同的端点。注意事实，与PUT,PATCH不是幂等的。这个请求应该返回整个实体或没有内容。
3. 当更高级的场景发挥作用时（例如可能有多个喜欢）POST绝对应该用于例如，增加点数或喜欢/不喜欢。请求应发送到/api/items/28/like|dislike。为什么POST？由于这是资源上的操作 - 使用动词而不是名词。这样的请求应该返回修改后的实体来跟踪状态。
4. 这是3的扩展 - 不仅你跟踪所有的喜欢，但喜欢可以删除，评论等在这种情况下，你引入一个新的资源：/likes和POST新的喜欢这个端点 - 在响应新的像返回。使用GET简单过滤/likes集合或POST/likes/filter如果需要预先过滤。