PATCH 与 POST - 增量计数器

Question

关于以Restful方式递增单个值的两个问题

假设我们有以下表格。

public class EmployeeStatistics   
{      
    public int Id { get; set; }
    public int EmployeeId { get; set; }
    public int CallsMade { get; set; }
    public int CallsRecieved { get; set; }
}

问题 #1

增加CallsMade 字段的正确格式是什么？

答：api/EmployeeStatistics/AddCallMade/EmpId/{empId}

乙：api/EmployeeStatistics/EmpId/{empId}/AddCallMade

问题 #2

POST 还是 PATCH？

网上有关于这个问题的相互矛盾的答案。

虽然 PATCH 用于替换特定值，但我不希望提供包含最终值的有效负载，而是希望触发服务器端事件，该事件递增指定值并返回状态代码 200 on完成。

如果我的理解是正确的，那么递增一个值并不是幂等的，因为每次运行操作时结果都会发生变化。这让我相信 POST 将是正确的解决方案。

感谢所有答案和意见，在此先感谢。

Answer 1

POST 还是 PATCH？

“这取决于”。 PATCH 与 PUT 一样，描述了以与域无关的方式对表示进行的更改。实际上，您是在告诉服务器“修改您的资源副本，使其看起来像 this。

大多数 PATCH 格式不提供“增量”操作；你得到的是set 或replace 语义（就像PUT 一样）。用 JSON PATCH 表示，你通常会看到这样的操作

{ "op": "replace", "path": "/CallsMade", "value": 42 }

或者，如果您试图确保没有丢失的编辑

{ "op": "test", "path": "/CallsMade", "value": 41 }
{ "op": "replace", "path": "/CallsMade", "value": 42 }

PATCH 也有原子变化语义

服务器必须以原子方式应用整个更改集，并且从不提供（例如，在此操作期间响应 GET）部分修改的表示。

因此，如果您实际上无法确保更改是全部还是全部；如果您不能将所有更改都放在一个“事务”中，那么 PATCH 就是错误的想法。

也就是说，您可以通过 PATCH 完成的所有操作也可以通过 POST 完成——POST 提供的保证更少。

增加 CallsMade 字段的正确格式是什么？

PATCH 与 PUT 和 DELETE 一样，描述了对资源表示的更改。通常的节奏是这样的

GET /X
(edit)
PATCH /X

REST 不关心标识符使用什么拼写，因此以下所有选项都同样可以接受

api/EmployeeStatistics/AddCallMade/EmpId/{empId}
api/EmployeeStatistics/EmpId/{empId}/AddCallMade
api/EDA9E9D4-EC6D-4884-91A6-F15BCE88D060

我们通常将path segments 用于分层数据，因此如果消费者希望编辑整个 EmployeeStatistic 实体，您可以使用这样的目标 URI

api/EmployeeStatistics/{empId}

或者像这样的目标 URI，如果您想提供仅限于与调用相关的信息的资源

api/EmployeeStatistics/{empId}/callsMade

您的消费者caches 上的结果并不完全相同，因此您需要仔细考虑资源的粒度。

使用 POST...好吧，使用 POST，您几乎可以做任何事情；它是 HTTP 方法的出狱卡。仍然存在缓存影响，但拥有一个可以增加任何员工的 callMade 的单一资源从根本上来说并没有错。