REST動詞 - 約定是「正確的」

我很好的實現了一個REST服務（在Windows CE平臺上，如果有的話），我開始使用POST的IBM's general definitions來創建（INSERTs）和PUT進行更新。REST動詞 - 約定是「正確的」

現在我已經跑過Sun's definitions這完全相反。所以我的問題是，這是「普遍接受的」定義？或者甚至有一個？

2010-03-15 ctacke

讓這個社會的維基，請，因爲「普遍接受」是很難牽制。 – 2010-03-15 14:09:38

使用PUT創建資源的缺點是客戶端必須提供唯一的ID來表示它正在創建的對象。儘管客戶端通常可以生成此唯一ID，但大多數應用程序設計人員更喜歡其服務器（通常在其數據庫中爲）創建此ID。在大多數情況下，我們希望我們的服務器可以控制資源ID的生成。那麼我們該怎麼辦？我們可以將切換爲使用POST而不是PUT。

所以：穿戴= UPDATE

郵政= INSERT

來源

2010-03-15 14:15:22

+1在密鑰創建問題上。 – 2010-03-15 16:08:39

雖然這會給出一個很好的理由，爲什麼有人可能會使用郵政的插入，它並沒有真正建立以此爲標準。對於使用Guids的人來說，身份證代不是問題。也許正確的答案是沒有普遍接受的標準。您可以使用您認爲最適合實施尊重REST原則的服務的HTTP動詞。 – 2011-05-18 00:02:43

我們使用POST = Create，PUT = Update。

爲什麼？有沒有好的原因。我們必須選擇一個，這就是我所做的選擇。

編輯。看看其他答案，我意識到關鍵創建問題可能會做出決定。

我們POST新條目並返回一個帶有生成的鍵的JSON對象。看起來這似乎更適合普遍接受的POST語義。

我們將PUT添加到標識對象的完整URI的現有條目中。

來源

2010-03-15 14:11:14

基本上只選擇一個，然後運行它。這是我（無意中）一樣 - 只是想確保我不會通過選擇慣例的倒數來迷惑我所有的客戶。 – ctacke 2010-03-15 14:14:41

「客戶」？請更新您的問題以解釋誰可能會感到困惑。 – 2010-03-15 16:08:12

通過「客戶」我的意思是，如果我爲我的客戶創建這個服務（他是誰付出的工作，而不是服務消費者應用程序），然後他們去，想擴展它，並添加更多的服務，他們最終不會感覺我對POST/PUT的使用與他們所看到的其他所有例子都是相反的。 – ctacke 2010-03-15 20:04:01

PUT可用於創建在服務器授予在它的URI空間的一部分，客戶端控制。這相當於文件系統中的文件創建過程：當您保存到尚不存在的文件時，創建該文件，如果該文件存在，則結果爲更新。

但是，PUT缺乏客戶端隱式意圖的能力。考慮下訂單：如果您將訂單/訂單/我的新訂單的含義只能更新由/訂單/我的新訂單標識的資源，而POST /訂單/可能意味着「發出新訂單」if POST接受資源具有適當的語義。

IOW，如果您想實現任何作爲創建新資源的副作用，您必須使用POST。

揚

來源

2010-03-15 14:38:30

使用POST作爲INSERT的原因和PUT作爲UPDATE是POST是根據HTTP唯一nonidempotent和不安全的操作。冪等性意味着無論您應用多少次操作，結果總是相同的。在SQL中，INSERT是唯一的非等效操作，所以它應該映射到POST。 UPDATE是冪等的，所以它可以映射到PUT上。這意味着相同的PUT/UPDATE操作可能會被應用多次，但只有第一次會改變我們的系統/數據庫的狀態。

因此，對於INSERT使用PUT將打破HTTP語義，即PUT操作必須是冪等的。

來源

2010-03-15 18:07:28

並非完全如此。如果你看看Cristian Boariu的回答。當客戶端提供ID時使用PUT插入時，具有相同ID的第二個PUT將覆蓋新創建的資源，而不是創建新資源。這將保持操作冪等。 – 2013-06-03 23:11:54

這裏http://www.w3.org/Protocols/rfc2616/rfc2616.html是如何實現的HTTP方法的行爲的官方指南。

來源

2010-03-15 18:12:15

Seroiusly？你的答案是「閱讀整個HTTP RFC」？它沒有談論REST或當今用於實現RESTful服務的標準約定。我編寫了我正在運行的Web服務器，所以我知道HTTP如何工作。我試圖在實現在該服務器上運行的REST服務時使用最佳實踐。 – ctacke 2010-03-15 20:02:05

Nah，爲了理解HTTP方法的工作方式，您只需要閱讀HTTP方法中的部分：-P。其中一個REST約束，統一接口，基本上意味着當通過HTTP進行REST時，RFC2616就是你的聖經。也許你正在尋找的是REST Cookbok，它是一套解決RESTful系統常見問題的標準配方.http：//www.amazon.com/RESTful-Web-Services-Cookbook-Scalability/dp/0596801688/ ref = sr_1_1？ie = UTF8＆s = books＆qid = 1268695534＆sr = 8-1 – 2010-03-15 23:26:22

動詞是：

GET {path}：檢索其標識符是{path}該資源。

PUT {path}：創建或更新標識爲{path}的資源。

DELETE {path}：刪除標識爲{path}的資源。

POST {path}：調用由{path}標識的操作。

當意圖創建新資源時，如果我們知道資源的標識符應該是什麼，那麼我們可以使用PUT，如果我們希望服務器確定新資源的標識符，我們可以使用POST。

來源

2010-03-15 18:13:32 yfeldblum

您對POST的定義與我鏈接的兩個文檔相矛盾。它似乎也表示使用一個動詞，我相信，它是不鼓勵的 – ctacke 2010-03-15 19:58:35

你是對的。我的定義與IBM和Sun的定義相矛盾，因爲IBM和Sun都搞錯了。請參閱http://en.wikipedia.org/wiki/Representational_State_Transfer#RESTful_web_services – yfeldblum 2010-03-16 02:53:59

上的示例和含義表請注意，GET，PUT和DELETE是標準哈希表（JavaScript對象，Ruby哈希， Python字典）的操作。在哈希表中，這些方法都是冪等的。相反，'POST'調用在服務上調用複雜方法的圖像，而不是對散列表執行簡單操作。實際上，'POST'適用於三個簡單散列表操作（'GET'，'PUT'和'DELETE'）不足的所有用例。 – yfeldblum 2010-03-16 03:11:43

我一直在學習的概念和REST的實現最近很多，一般的共識似乎是：PUT用於取決於資源是否已經存在，創建/更新。 POST用於將資源追加到集合。

參見HTTP/1.1方法的定義http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

POST被設計成允許一個統一的方法，以覆蓋下面的功能：
- Annotation of existing resources; 

    - Posting a message to a bulletin board, newsgroup, mailing 
    list, or similar group of articles; 

    - Providing a block of data, such as the result of submitting a 
    form, to a data-handling process; 

    - Extending a database through an append operation. 
將所附實體下儲存的PUT方法請求提供了Request-URI。如果Request-URI引用已存在的資源，則封閉實體應該被認爲是原始服務器上駐留的實體的修改版本。

另請參閱接受的問題答案Understanding REST: Verbs, error codes, and authentication。

來源

2011-08-25 05:03:43 Herbert

REST動詞 - 約定是「正確的」

回答

相關問題