好的POST空的正文，在響應中傳遞數據？

我希望客戶端能夠通過HTTP請求（無論哪個文檔位於服務器的輸出隊列的頭部），同時瞭解如果檢索成功，文檔將自動從隊列中刪除。每臺服務器上不會有多個客戶端，但客戶端可能是多線程的。沒有對隊列的隨機訪問;只有頭項目可以被檢索（和刪除）。我還沒有在這裏或網絡上的其他地方發現過這種情況。以下是我能想到的各種方法：（1）客戶端可以發送GET請求。但GET不應該有副作用，所以這似乎不是一個好主意。（2）客戶端可以發送兩個請求，一個GET在隊列頭部檢索文檔，一個DELETE（用空或可忽略的URL）刪除隊列頭部的文檔。但是這需要兩次調用，這可能會導致各種問題，特別是如果客戶端中的多個線程/進程試圖檢索文件。好的POST空的正文，在響應中傳遞數據？

（3）客戶端可以發送POST請求與一個空的身體;如果隊列頭部有文檔，則服務器將返回其正文包含文檔的響應，並且還將從隊列中刪除文檔。這有點違反直覺，因爲它不符合發佈數據和接收簡單返回代碼的心理模型，但除此之外，我喜歡它。我並不擔心在運輸途中丟失的回覆以及文件丟失;我希望連接足夠安全以防止這種情況發生。

如果有另一種HTTP方法來處理這種情況，那將是很好的，但是由於沒有，我認爲（3）是最好的方法。同意？不同意？

更新：在閱讀Dan675的帖子後添加（4）。（4）客戶端可以發送一個DELETE請求，服務器可以向主體發送一個響應（當然，從隊列中刪除文檔）。再說一次，這有點違反直覺（當你想要檢索它時，你通常不會說「爲我刪除堆棧上的項目，請」），但會起作用。

來源

2012-02-22 Alan

網址總是相同，但每個「操作」都有不同的文檔？ – dash 2012-02-22 21:30:49

是的，URL總是相同的，是的，每次文檔都應該不同（除非同一個文檔被多次提交給輸入隊列，這是我們無法預防的）。 – Alan 2012-02-22 21:34:39

我同意1）是最簡單的，但語義不正確，2）是正確的，但實現起來更復雜，3）是一個很好的折衷方案，但仍然在語義上不正確。 – dash 2012-02-22 21:37:09

它應該在兩個調用中完成，第一個是GET，第二個是刪除它。

如果刪除成功，則客戶端請求有效，否則請將其視爲整個請求失敗並嘗試再次獲取隊列頂部的內容。這會由於請求失敗而導致額外的開銷，但我不會推薦執行其他選項。

我想這樣做的另一種方法是先做一個PUT，以某種方式將最頂端的項目標記爲'reserved'，然後執行GET和DELETE。通過這種方式，可以遍歷此服務器端隊列並查找不是「保留」的最頂級項目。

來源

2012-02-22 21:33:42 Dan675

+1將它放在保留隊列上，從保留隊列中獲取它，然後從保留隊列中刪除它。好主意。 – dash 2012-02-22 21:38:48

看來你的操作速度很關心，不想引入這些建議的開銷，所以我會說你的新選項，第4個數字是最有效的。 – Dan675 2012-02-22 21:52:43

我想我只是想知道什麼保留該項目，無論是在現有的隊列或單獨的一個，將購買我們，特別是因爲只有最上面的項目應該可訪問。一旦文件被檢索，我知道它可以被刪除。 – Alan 2012-02-22 21:54:37

好的POST空的正文，在響應中傳遞數據？

回答

相關問題