【SAP|SAP ABAP Gateway Client 里 OData 测试的 PUT, PATCH, MERGE 请求有什么区别】相信不少朋友在使用 SAP ABAP Gateway Client 测试 OData 服务时，都看到过这三个相似的 HTTP 请求类型：PUT, MERGE 和 PATCH.
文章图片
这三种类型有什么区别呢？
- PUT：将 HTTP 请求（payload）作为输入，这个输入将被传入 OData 模型的 DPC Class 的 UPDATE_ENTITY 方法中。
{ “Vbkur” : “170” }则只有 Vbkur 在 update_entity 方法中可见。 总之，如果将 OData 模型的
属性子集(attribute subset)作为 PUT 方法的输入，则相同的属性子集将会被传入 UPDATE_ENTITY 方法进行处理。- PATCH & MERGE: 如果在有效负载（HTTP 请求）中传递属性的子集，这两个方法会自动获取其他属性。 Patch 和 Merge 的行为方式相同，但基本区别在于 PATCH 支持 OData 3.0 协议，而 MERGE 支持 OData 1.0 和 2.0 协议。 因此我们应该优先使用 PATCH，而不是 MERGE.
{
"Vbeln" : "32346",
"Erdat" : "\/Date(1627171200000)\/",
"Erzet" : "PT19H29M37S",
"Ernam" : "FIORIUSER",
"Audat" : "\/Date(1627171200000)\/",
"Netwr" : "193.050",
"Waerk" : "USD",
"Vkorg" : "1710",
"Vtweg" : "10",
"Vkbur" : "180"
}当我们使用 PATCH 操作时，仅仅传递一个待修改属性：
文章图片
但是在 DPC 的 UPDATE_ENTITY 方法内，订单抬头的所有字段都可以访问：
文章图片
SAP ABAP OData 框架每当触发 PATCH 或 MERGE 调用时，它将首先触发相应的 GET_ENTITY(collect all properties) 方法，然后才执行 UPDATE_ENTITY 方法。
文章图片
注意：由于 MERGE 不是 HTTP 规范 [RFC2616] 中定义的动词之一，因此使用 MERGE 动词可能不会像 HTTP 规范中定义的方法那样无缝地通过网络中介。 在处理支持 OData 3.0 协议的数据服务时，HTTP PATCH 动词优先于 HTTP MERGE。 支持 OData 2.0 和 OData 3.0 协议的数据服务可以支持动词隧道以减轻此限制。
