為微服務構建REST API時，需要做出一些關于響應的設計決策。 某些響應顯然是微服務周圍協議的產物–例如3xx代碼之類的東西都與重定向和路由有關。

通常，您將嘗試獲取正確的2xx代碼以取得成功。 如有疑問，將為200（確定），但對于打算創建數據的請求，請考慮201（已創建），對于將在以后處理的請求，請考慮202（已接受）。

在本文中，我想討論用于錯誤的4xx和5xx響應。 我還要考慮您的服務是否將嘗試容忍下游錯誤。 您希望軟件變得越復雜，內部異常就越精確。

確切地說，我的意思是簡單。

笨拙的異常處理策略最終將導致艱苦的工作來應對所有用例。

簡化簡化簡化

此刻，每當我被要求對微服務中的異常和錯誤提出意見時，我都會回答相同的答案。

有兩類錯誤的...它出了問題，或者你就錯了。

你錯了

客戶端錯誤最容易檢測，需要與響應代碼一樣精確的錯誤處理。 通常，404錯誤并不是真正的例外，就如同返回零結果一樣。 對于其他錯誤，您基本上得到了：

• 安全違規，在處理請求之前應在適當的框架中進行檢查
• 無效的請求-通常是畸形的身體

容易忘記，如果隨機的Json解析異常發生在正確的層，則可以簡單地將其歸類為您錯了。

一旦知道了要嘗試證明的簡單分類，就可以輕松地了解要做什么和要測試什么。

錯了

這些錯誤分為兩類：

• 我的算法無法解決這種情況-對不起
• 某些下游服務無法正常工作

在這兩個中，后者可能有一些變體，其中需要對錯誤應用重試策略，以便在給我們之前再次提出請求，從而避免出現網絡故障，或者避免與多個相關服務進行某種機會游戲，目前其中任何一個都可能會出現故障。

提示：如果要獲得回應就像Yahtzee的游戲一樣，則需要添加一些重試，并且這些重試應該在明確定義的可重試范圍內， 但出錯了。

如果您的重試策略錯誤，它將重試以下內容：

• 我的算法無法應付
• 該請求永遠不會有效

當然，生活中的事物不可能是二進制的嗎？

有兩種類型的人。 有人認為一切都是二元選擇，然后還有其他人……

從標題的二進制選擇開始是一個很好的/強烈的起點。 然后在必要時將每個類別分為子類別，可以幫助您處理特定的細微差別。

到目前為止，這對我們有用。

您可以逐步建立。

有兩種類型的人員：懂得如何逐步構建事物的人員，以及……我將在另一天告訴您另一種類型的人員。

翻譯自: https://www.javacodegeeks.com/2020/03/it-broke-vs-youre-wrong.html

總結

以上是生活随笔為你收集整理的打破了vs你错了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。