相信不少朋友在使用 SAP ABAP Gateway Client 測試 OData 服務時，都看到過這三個相似的 HTTP 請求型別：PUT, MERGE 和 PATCH.

![](https://img-blog.csdnimg.cn/img_convert/aff3ae61229a822890f1ebf1db1d7f36.png)

這三種型別有什麼區別呢？

- PUT：將 HTTP 請求（payload）作為輸入，這個輸入將被傳入 OData 模型的 DPC Class 的 UPDATE_ENTITY 方法中。

例如我們透過 PUT 傳入如下的資料：

```json
{ “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.

舉個例子，下列是訂單的抬頭屬性欄位集合：

```json
{
    "Vbeln" : "32346",
    "Erdat" : "\/Date(1627171200000)\/",
    "Erzet" : "PT19H29M37S",
    "Ernam" : "FIORIUSER",
    "Audat" : "\/Date(1627171200000)\/",
    "Netwr" : "193.050",
    "Waerk" : "USD",
    "Vkorg" : "1710",
    "Vtweg" : "10",
    "Vkbur" : "180"
}
```

當我們使用 PATCH 操作時，僅僅傳遞一個待修改屬性：

![](https://img-blog.csdnimg.cn/img_convert/5f23ab07eba8aecebb91154c9cea4f90.png)

但是在 DPC 的 UPDATE_ENTITY 方法內，訂單抬頭的所有欄位都可以訪問：

![](https://img-blog.csdnimg.cn/img_convert/f109a2da6d8a254dac2ed5eb1c6162d6.png)

SAP ABAP OData 框架每當觸發 PATCH 或 MERGE 呼叫時，它將首先觸發相應的 GET_ENTITY(collect all properties) 方法，然後才執行 UPDATE_ENTITY 方法。

![](https://img-blog.csdnimg.cn/img_convert/544ae8718f0c6b2ce7e8a321cbf56128.png)

注意：由於 MERGE 不是 HTTP 規範 [RFC2616] 中定義的動詞之一，因此使用 MERGE 動詞可能不會像 HTTP 規範中定義的方法那樣無縫地透過網路中介。 在處理支援 OData 3.0 協議的資料服務時，HTTP PATCH 動詞優先於 HTTP MERGE。 支援 OData 2.0 和 OData 3.0 協議的資料服務可以支援動詞隧道以減輕此限制。

SAP ABAP Gateway Client 裡 OData 測試的 PUT, PATCH, MERGE 請求有什麼區別

相關文章