由於POST/Redirect/GET（PRG）模式中的POST請求返回成功時的重定向（303 See Other）狀態碼，是否可以通知（例如，OK，Created，Accepted等）以及任何適當的標題（例如Location爲201 Created，這可能與重定向的衝突）相沖突的客戶端？POST/Redirect/GET（PRG）與有意義的2xx響應代碼
例如，讓重定向的GET響應正確的響應代碼&標題可能會從POST響應中預期？
的HTTP 1.1規範說：
此方法[303]的存在主要以允許POST激活腳本的輸出向用戶代理重定向到所選擇的資源。
但是沒有提供任何有關更常見狀態代碼和標頭丟失的信息。
編輯 - 一個例子：
客戶端發送POST請求/orders其產生在/orders/1新資源。
如果服務器發送201 Created狀態location: /orders/1，自動化客戶端會很高興，因爲它知道資源已創建，它知道它在哪裏，但使用Web瀏覽器的人會不高興，因爲他們得到頁面/orders，如果他們刷新它們將發送另一個訂單，這不太可能是他們想要的。
如果服務器發送303 See Other狀態location: /orders/1人將被採取他們的順序，通知其存在和狀態，並不會有意外重複它的危險。但是，自動化客戶端不會被明確告知資源的創建，它必須根據location標題推斷創建。此外，如果303重定向到其他地方（例如，/users/someusername/orders），那麼人類可能會很好地適應，但自動化客戶端卻很不明智。
我的建議是，發送201 Created作爲響應對新資源重定向的GET請求，但我越去想它，我喜歡它的少（可能會非常棘手，以確保只有創建者接收201，它不應該出現請求創建資源的GET）。
這種情況下的最佳響應是什麼？
你能舉一個你想到的例子嗎？ – Gumbo 2010-08-03 16:07:30
我編輯了這個問題來提供一個例子。謝謝。 – 2010-08-05 16:01:31
需要說明的是：您已經確保了一個人類用戶會對剛剛發生的事情瞭如指掌，現在您正在嘗試爲自動化產品做同樣的事情？ – sdleihssirhc 2011-02-02 23:42:05