2010-02-04 79 views
2

我不知道該HTTP代碼是一個獨特的方案是正確的選擇。選擇正確的HTTP返回代碼爲未來的資源

客戶端可以通過使用PUT到預先已知URI上傳實體。然後,該實體在服務器上處理,這可能需要一些時間(即,轉碼/處理)。如果這樣做,資源在它上傳到的URI下可用。

現在我不能確定這是正確的HTTP響應代碼返回,如果做處理之前的客戶端查詢資源。我正在尋找類似於410 Gone的對面。由於應用程序體系結構的原因,不同的客戶端在處理完成之前會知道URI(至少是做過上傳的客戶端)。

此外,我不想使用WebDAV擴展的代碼,雖然會有一些有效的。

我有一些初步的想法,但我不知道哪個最適合:

  • 307 Temporary Redirect重定向到佔位符資源。
  • 405 Method Not Allowed GET只被允許後=>客戶端必須不緩存這個答案。
  • 503 Service Unavailable強調在服務器端錯誤=>也許對於客戶究竟有錯有些不清楚。
  • 還有其他想法嗎?

我應該選擇?

回答

3

你可以返回一個202接受響應初始PUT,然後204無內容任何GET請求,直到表示是可用的。

+0

另外想到的那一個,但是根據RFC2616:「這個響應的主要目的,以允許輸入用於行動發生而不引起改變到用戶代理的活動文檔視圖,儘管任何新的或更新的元信息應該被施加到該文檔當前處於用戶代理的活動視圖中。「 這真的是我想表達的嗎? – 2010-02-04 15:50:53

+0

它從無到有,這似乎是有道理的。 – Mike 2010-02-04 15:52:40

0

有您的使用情況下,沒有特定的HTTP代碼。也許你想使用WebDAV的擴展名423 LOCKED

423(鎖定)狀態碼錶示方法的源或目標資源被鎖定。

+0

正如我在我的問題中已經寫過的,我不想使用WebDAV代碼。 – 2010-02-04 15:45:44

0

返回202和一個響應正文,其中包含狀態和指向可監視狀態的資源的鏈接。

當有人得到還沒有準備好資源,用307來臨時。重定向到該監控頁面。

這要求客戶端了解包含監視資源鏈接的實體媒體類型,因此,在機器對機器系統中,如果您使用此類系統,您需要爲此提供媒體類型或至少使用某種微格式HTML。