每個(gè)HTTP請求都包含一個(gè)方法 （有時(shí)稱為verb ），該方法指示對標(biāo)識的資源執(zhí)行的操作。

在構(gòu)建RESTful Web服務(wù)時(shí)，HTTP方法POST通常用于創(chuàng)建資源，而PUT用于資源更新。 盡管在大多數(shù)情況下這很好，但使用PUT進(jìn)行資源創(chuàng)建也是可行的。 PATCH是資源更新的替代方法，因?yàn)樗试S部分更新。

一般來說，我們可以說：

• POST請求在服務(wù)器定義的URI上創(chuàng)建子資源。 POST也用作常規(guī)處理操作
• PUT請求在客戶端定義的URI處創(chuàng)建或替換資源
• PATCH請求在客戶端定義的URI上更新資源的一部分

但是，讓我們多看一些細(xì)節(jié)，看看如何在HTTP規(guī)范中定義這些動(dòng)詞。 這里的相關(guān)部分是HTTP RFC（2616）的第9節(jié)。

開機(jī)自檢

RFC將POST的功能描述為：

POST方法用于請求源服務(wù)器接受請求中包含的實(shí)體作為請求行中Request-URI標(biāo)識的資源的新下屬。

這允許客戶端創(chuàng)建資源而無需知道新資源的URI。 例如，我們可以向/ projects發(fā)送POST請求以創(chuàng)建一個(gè)新項(xiàng)目。 服務(wù)器現(xiàn)在可以將項(xiàng)目創(chuàng)建為/ project的新下屬，例如： / projects / 123 。 因此，在使用POST進(jìn)行資源創(chuàng)建時(shí)，服務(wù)器可以確定新創(chuàng)建的資源的URI（通常是ID）。

服務(wù)器創(chuàng)建資源時(shí)，應(yīng)以201（已創(chuàng)建）狀態(tài)代碼和一個(gè)指向新創(chuàng)建資源的Location標(biāo)頭進(jìn)行響應(yīng)。

例如：

請求：

POST /projects HTTP/ 1.1 Content-Type: application/json { "name" : "my cool project" , ... }

響應(yīng)：

HTTP/ 1.1 201 Created Location: https: //cool.api.com/projects/123

POST不是冪等的 。 因此，多次發(fā)送相同的POST請求可能會導(dǎo)致創(chuàng)建多個(gè)資源。 根據(jù)您的需求，這可能是一個(gè)有用的功能。 如果沒有，則應(yīng)該進(jìn)行一些驗(yàn)證，并確保僅根據(jù)某些自定義條件（例如，項(xiàng)目名稱必須唯一 ）創(chuàng)建一次資源。

RFC還告訴我們：

POST方法執(zhí)行的操作可能不會導(dǎo)致可以由URI標(biāo)識的資源。 在這種情況下，適當(dāng)?shù)捻憫?yīng)狀態(tài)是200（確定）或204（無內(nèi)容），這取決于響應(yīng)是否包括描述結(jié)果的實(shí)體。

這意味著POST不一定需要?jiǎng)?chuàng)建資源。 它也可以用于執(zhí)行一般操作（例如，開始批處理作業(yè)，導(dǎo)入數(shù)據(jù)或處理某些操作）。

放

POST和PUT之間的主要區(qū)別是請求URI的含義不同。 HTTP RFC表示：

POST請求中的URI標(biāo)識將處理封閉實(shí)體的資源。 [..]相反，PUT請求中的URI標(biāo)識請求[..]內(nèi)的實(shí)體，并且服務(wù)器不得嘗試將請求應(yīng)用于其他資源。

對于PUT請求，客戶端需要知道資源的確切URI。 我們無法將PUT請求發(fā)送到/ projects，并期望在/ projects / 123上創(chuàng)建一個(gè)新資源。 相反，我們必須將PUT請求直接發(fā)送到/ projects / 123 。 因此，如果我們要使用PUT創(chuàng)建資源，則客戶端需要知道（如何生成）新資源的URI / ID。

在客戶端能夠?yàn)樾沦Y源生成資源URI / ID的情況下，PUT實(shí)際上應(yīng)優(yōu)先于POST。 在這些情況下，資源創(chuàng)建通常是冪等的 ，這是對PUT的明確提示。

可以使用PUT創(chuàng)建和更新資源。 因此，將PUT請求發(fā)送到/ projects / 123可能會創(chuàng)建項(xiàng)目（如果該項(xiàng)目不存在）或替換現(xiàn)有項(xiàng)目。 HTTP狀態(tài)代碼應(yīng)用于通知客戶端資源是否已創(chuàng)建或更新。

HTTP RFC告訴我們：

如果創(chuàng)建了新資源，則原始服務(wù)器務(wù)必通過201（已創(chuàng)建）響應(yīng)通知用戶代理。 如果修改了現(xiàn)有資源，則應(yīng)發(fā)送200（確定）或204（無內(nèi)容）響應(yīng)代碼以指示請求已成功完成。

一般而言，如果確切的資源URI是已知的并且操作是冪等的 ，則PUT通常是比POST更好的選擇。 在大多數(shù)情況下，這使PUT成為更新請求的理想選擇。

但是，對于資源更新，應(yīng)該記住一個(gè)怪癖。 根據(jù)RFC，PUT應(yīng)該用新資源替換現(xiàn)有資源。 這意味著我們無法進(jìn)行部分更新。 因此，如果要更新資源的單個(gè)字段，則必須發(fā)送包含完整資源的PUT請求。

補(bǔ)丁

HTTP PATCH方法在RFC 5789中定義為對前面提到的HTTP RFC的擴(kuò)展。 當(dāng)使用PUT替換現(xiàn)有資源時(shí)，使用PATCH對資源進(jìn)行部分修改。

引用RFC：

使用PATCH [..]，封閉的實(shí)體包含一組指令，這些指令描述應(yīng)如何修改當(dāng)前駐留在原始服務(wù)器上的資源以產(chǎn)生新版本。 PATCH方法影響由Request-URI標(biāo)識的資源，并且可能對其他資源也有副作用。

因此，類似于POST的PATCH也可能會影響請求URI所標(biāo)識資源以外的資源。

通常，PATCH請求使用與應(yīng)更新的資源相同的格式，而忽略了不應(yīng)更改的字段。 但是，不必一定是這種方式。 也可以使用單獨(dú)的修補(bǔ)程序格式 ，該格式描述了如何修改資源。

PATCH既不安全也不是冪等的 。

也許您想知道在哪些情況下部分資源更新不是冪等的。 這里的一個(gè)簡單示例是將項(xiàng)目添加到現(xiàn)有列表資源中，例如將產(chǎn)品添加到購物車中。 多個(gè)（部分）更新請求可能會將產(chǎn)品多次添加到購物車中。

翻譯自: https://www.javacodegeeks.com/2020/02/rest-http-methods-post-vs-put-vs-patch.html

總結(jié)

以上是生活随笔為你收集整理的REST / HTTP方法：POST与PUT与PATCH的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。