「最佳嘗試」的HTTP響應代碼

我有一個服務（façade）需要一個「令牌」，然後解碼它以檢索某些信息（一個id），然後調用另一個外部服務來獲取一些附加信息。「最佳嘗試」的HTTP響應代碼

{"id":"foo","other-stuff":"bar"}

由於此服務依賴於外部服務，因此有時可能會失敗;不過，我們希望它仍然可以返回它設法檢索自己的信息。

{"id":"foo","warning":"bar service is down, oh no!"}

顯然，在第一種情況中200返回碼是合適的，但它仍然在適當的時候爲「部分」不成？作爲一個消費者，我認爲我寧願只是閱讀狀態代碼，然後向用戶顯示警告或任何其他信息;所以200在這裏對我不是很有幫助。

任何想法？

來源

2013-06-03 qui

在兩種情況下發送相同的狀態碼都不是一種好的做法。您需要驗證外部服務是否已啓動並正在運行。換句話說，您可以將其視爲一種特殊情況。如果外部服務未啓動並運行，則可以通過例外來觸發該情形。在那裏你將能夠追上從外部服務返回的狀態碼。如果適合您的解決方案，則可以發送該狀態碼，否則您可以設置自定義狀態碼並將其發送回客戶端。

來源

2013-06-03 13:56:18 MCF

但是，如果我只是返回外部服務（即503），這將意味着的狀態代碼*我*服務也暫時不可用，這是不正確的;它仍然可以返回一些信息 – qui

你或許應該使用404 - 找不到範圍。 – MCF

當涉及到REST API開發時，您不能考慮下劃線服務是否未運行，並且只有您的服務正在運行是一個很好的條件。你可以給出一個自定義錯誤代碼，它應該是1000+範圍（例如：1025） – MCF

根據外部因素，暫時服務器端故障的正確響應代碼是503 Service Unavailable。 From the specification：

服務器目前無法處理該請求，由於服務器的暫時超載或維護。其含義是，這是一個暫時的情況，延遲一段時間後將會緩解。如果已知，延遲的長度可以在 Retry-After標題中指示。如果沒有給出Retry-After，那麼客戶端應該處理響應，就像處理500響應一樣。

考慮到它的部分故障違反了整個HTTP的事務性 - 請求要麼失敗，要麼失敗。如果由於服務器端問題而無法成功完成整個請求，則5xx答案根據規範是唯一適當的響應。

我不知道你的Web服務是如何工作的，但如果情況真的是，你是接觸多個上游數據提供者，它本身並不是有害的客戶端得到部分緩解，你應該提供它在你自己的協議中，它列出了正確檢索的元素，以及緩存或不能提供的元素。在這種情況下，你的迴應實際上是一個有效的答案的要求，並應與200 OK傳遞。此方案相當於有一個網站上的Twitter的飼料 - 如果Twitter是，你還是能夠獲得含有所有的其他內容是「目前Twitter的飼料不可用消息」一個有意義的答案。一個有意義的答案會那麼仍然當然200 OK發送。

來源

2013-06-03 13:59:54

我看到你在說什麼，但能夠返回一些有用的信息對消費者有用，它將允許用戶仍然以有限的方式使用該網站;這總比沒有好。有人可能會說我仍然可以返回數據並執行503，但這意味着實際服務已經停止;它不覺得語義上正確。 – qui

沒有在這種情況下，我添加的最後一段適用 - 在這種情況下，你發送一個有效的答案，這應該通過'200 OK'發送。成功傳輸的響應包含一些錯誤消息與響應的HTTP層無關。 '503'明確表示*「我現在無法給出有意義的迴應，但我可能會遲一點」*。 –

嗯，也許。當我作爲客戶端使用代碼時，我會想要實現類似於斷開對服務的調用的電路;我期望503的意思是「不要打我5分鐘，我有問題」。用我的場景，如果我返回一個503，我現在需要檢查代碼*和*的響應，這更多..煩人:)我想我的觀點是，這將是很好，如果有一個適當的HTTP代碼，我可以使用而不是必須解析響應才能解決發生的事情。 – qui

「最佳嘗試」的HTTP響應代碼

回答

相關問題