修補程序http方法的REST完整api響應應如何？

Question

我在服務器上有訂單資源。 網址看起來像http://example.net/order/1 ，上面網址的get方法將返回整個訂單對象，例如

    {
    "orderNo": "1",
    "status": "order place",
    "orderTimestamp": "2018-11-22 14:28:12",
   "invoiceAddress": {
        "salutation": "M",
        "firstName": "Dieter",
        "lastName": "Wolf",
        "companyName": "",
        "street": "Michaelkirchstr.",
        "houseNo": "16",
        "zipCode": "31604",
        "city": "Raddestorf",
        "countryIsoCode": "DEU",
        "phone": "05763 82 60 80",
        "email": "DieterWolf@armyspy.com"
    },
    "deliveryAddress": {}
    "items": [
        {
            ...
        }
    ],
    "returnItemsDetails": []
}

現在，我希望在同一個api上提供補丁方法，以便可以更新/添加一些細節，例如交貨地址。 要更新訂單詳細信息，可以在同一訂單網址上請求帶有補丁http方法的后續請求

{
    "deliveryAddress": {
        "deliveryType": "CUSTOMER",
        "salutation": "M",
        "firstName": "Dieter",
        "lastName": "Wolf",
        "companyName": "",
        "street": "Michaelkirchstr.",
        "houseNo": "16",
        "zipCode": "31604 ",
        "city": "Raddestorf",
        "countryIsoCode": "DEU",
        "phone": "05763 82 60 80",
        "email": "DieterWolf@armyspy.com"
    }
}

我的問題是，根據REST標准，響應補丁請求應該有什么？ 或是否可以找到有關REST api的響應數據和格式的任何文檔。

Answer 1

我的問題是，根據REST標准，響應補丁請求應該有什么？ 或是否可以找到有關REST api的響應數據和格式的任何文檔。

修補程序在RFC 5789中定義。 第2節演示了一種可能性，您將返回資源的更新表示：

如果對此方法的響應包含顯式的新鮮度信息（例如Expires標頭或“ Cache-Control：max-age”指令）以及與Request-URI匹配的Content-Location標頭，則表明該方法的響應是可緩存的，這表明PATCH響應主體是資源的表示形式。

但是我找不到更一般情況的規范。 因此，我的建議是，解釋RFC 7231中關於PUT和DELETE的規范也適用於PATCH

動作狀態的表示

Answer 2

我的問題是，根據REST標准，響應補丁請求應該有什么？ 或是否可以找到有關REST api的響應數據和格式的任何文檔。

根據RFC 5789 ，成功響應可以返回任何成功代碼（即200或204）。 理想情況下，它還應包含一個ETag頭，以允許客戶端跟蹤當前版本以進行最終的連續請求（基本上用於樂觀鎖定資源狀態）。

規范提出了一個204 No Content示例，因為從廣義上講，補丁是由客戶端計算的一組指令組成的，該指令是服務器應應用以將目標資源轉換為所需狀態。 因此，客戶端可以事先知道最終結果的外觀，因此服務器無需將其告知客戶端。

如果您想返回200 OK響應，我建議返回由客戶端發出的Accept request標頭建議的表示形式（Content-Type協商），以避免強迫客戶端使用某些可能無法理解或原因的預定義媒體類型格式來自更多的可能性。

如果您需要對資源進行不可預測的更改，即基於服務器端進行的某些計算，或者將有效負載包含到某個預定義的元素中（如您的示例中可能所做的那樣），則RFC 5789明確指出應使用POST而不是PUT或PATCH 。 進一步請注意，您可以支持application/merge-patch+json媒體格式及其在RFC 7386中定義的語義，以將這樣的（樣本）正文作為有效載荷發送給PATCH請求，並且可能實現所需的結果。