关于abap:SAP-ABAP-Gateway-Client-里-OData-测试的-PUT-PATCH-MERGE-请求有什么区别

98次阅读

共计 983 个字符，预计需要花费 3 分钟才能阅读完成。

置信不少敌人在应用 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 协定的数据服务能够反对动词隧道以加重此限度。

正文完