置信不少敌人在应用 SAP ABAP Gateway Client 测试 OData 服务时，都看到过这三个类似的 HTTP 申请类型：PUT, MERGE 和 PATCH.
这三种类型有什么区别呢？
- PUT：将 HTTP 申请（payload）作为输出，这个输出将被传入 OData 模型的 DPC Class 的 UPDATE_ENTITY 办法中。
例如咱们通过 PUT 传入如下的数据：
{“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 协定的数据服务能够反对动词隧道以加重此限度。