執行時間長的REST請求的方法？

Question

我們正在構建一個REST服務，需要大約5分鐘才能執行。它只會被一個內部應用程序每天調用幾次。使用需要5分鐘才能完成的REST（即：HTTP）請求是否存在問題？

難道我們擔心超時？我們是否應該在服務器的另一個線程中啓動請求，並讓客戶端輪詢狀態？

Answer 1

假設你可以HTTP超時使用你選擇的框架，那麼你可以通過一個GET請求只是掛5分鐘配置。

但是，通過POST啓動執行，獲取收據（數字/ ID無關）可能更靈活，然後在5分鐘後執行GET操作（也可能重試，因爲您的過程不會每次只需5分鐘）。如果請求仍在進行中，則返回一個適當的HTTP錯誤代碼（可能是404，但是您將返回一個帶有不存在收據的GET？），或返回結果（如果可用）。

Answer 2

如果你控制兩端，那麼你可以做任何你想要的。例如。瀏覽器傾向於使用「連接關閉」標題啓動HTTP請求，因此您只剩下更少的選項;-)

請記住，如果您之間有一些NAT /防火牆，如果它們是一段時間不活動。

難道我建議註冊一個「回調」過程？客戶端向服務器發出帶有「回調終點」的請求，獲得「票據」。一旦服務器完成，它將「回調」客戶端......或客戶端可以通過票證標識符檢查請求的狀態。

Answer 3

這是一種方法。

創建一個新的請求執行ProcessXYZ

POST /ProcessXYZRequests 

201-Created 
Location: /ProcessXYZRequest/987 

如果你想看到的請求的當前狀態：

GET /ProcessXYZRequest/987 

<ProcessXYZRequest Id="987"> 
    <Status>In progress</Status> 
    <Cancel method="DELETE" href="/ProcessXYZRequest/987"/> 
</ProcessXYZRequest> 

當請求完成後，你會看到類似

GET /ProcessXYZRequest/987 

<ProcessXYZRequest> 
    <Status>Completed</Status> 
    <Results href="/ProcessXYZRequest/Results"/> 
</ProcessXYZRequest> 

使用這種方法，你可以很容易地想象一下以下請求W¯¯應該給

GET /ProcessXYZRequests/Pending 
GET /ProcessXYZRequests/Completed 
GET /ProcessXYZRequests/Failed 
GET /ProcessXYZRequests/Today 

Answer 4

正如Brian Agnew指出的那樣，5分鐘完全可以管理，如果有點浪費資源，如果可以控制超時設置的話。否則，必須至少提出兩個請求：第一個獲取結果生成過程，第二個（第三個，第四個，第等，如果結果花費比預期更長的時間編譯）來輪詢結果。

Brian Agnew和Darrel Miller都提出了兩種（+） - 步驟方法的類似方法：向工廠端點發布請求，在服務器上啓動一個作業，然後從返回的結果端點獲取結果。

雖然上面是一個很常見的解決方案，也確實堅持的REST約束的信，它的氣味非常RPC的。也就是說，而不是說，「爲我提供這個資源的表示」，它說：「運行此工作」（RPC），然後在「我提供的資源的表示是運行作業的結果」 （休息）。 編輯：我在這裏說得很鬆散。要明確，這些都沒有明確地違反REST約束條件，但它確實非常類似於在REST服裝中修飾非REST風格的方法，在這個過程中失去了它的好處（，例如緩存，冪等性）。因此，我寧願建議當客戶端第一次嘗試獲取資源時，服務器應該以202「Accepted」（http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3）響應，也許在響應實體的某個地方用「5分鐘後嘗試」響應。此後，客戶端可以查詢同一端點得到結果，如果有的話（否則返回另一個202，並稍後重試）。

這種方法的一些額外的好處是，一次性使用的資源（如作業）不會不必要地創建，不需要查詢兩個單獨的端點（工廠和結果），並且同樣不需要從解析中確定第二個端點來自第一個的響應，因此更簡單。此外，結果可以被緩存，「免費」（代碼方式）。根據結果​​「有效」的時間長度，在結果頭中設置緩存過期時間，在某種意義上說，針對問題域。

我希望我可以稱之爲「資源導向型」方法的典型例子，但是，也許具有諷刺意味，「REST Web服務」的第8章提出的兩個端點，工廠的做法。去搞清楚。