例外的建議JSON結構？

出於好奇，在返回JSON的API中是否有返回服務器端異常（和相應的細節）的流行標準？異常可能來自代碼中未捕獲的異常或開發人員拋出的異常。例外的建議JSON結構？

目前，我根據自己的Wiki definitions'

我的JSON響應設置HTTP狀態代碼會是這個樣子：

HTTP Code: 401 

{'error': 'Authentication required.', 'message': 'You must be authenticated to perform that action.'}

來源

2012-08-05 used2could

你可以看看JSON-RPC（http://en.wikipedia.org/wiki/JSON-RPC）。

在成功的情況下，響應是這樣的：

{ 
    "result": ...(returned data)... 
    ... 
}

和在發生錯誤的情況下，響應是這樣的：

{ 
    "error": ...(error details)... 
    ... 
}

當發生錯誤，「錯誤」屬性必須存在並且「結果」屬性不得退還。如果沒有錯誤，則不能設置「錯誤」屬性。通過這種方式，您可以僅根據響應內容區分成功響應中的錯誤，而無需檢查標題（如響應代碼）。

來源

2012-08-05 17:12:19 Tadeck

是的，你可以這樣做。

我們知道，Web服務器允許我們創建了HTTP錯誤自定義錯誤頁，在這些自定義錯誤頁，你必須服務於JSON回覆

例子：
添加以下到你的WEB-INF /web.xml：

<error-page> <error-code>401</error-code> <location>/autherror.jsp</location> </error-page>

在autherror.jsp文件中，代碼完成所需的JSON回覆所需的邏輯代碼。

來源

2012-08-05 16:53:04

天然的ECMAScript誤差對象的標準結構爲：

{ 
    name: ..., 
    message: ... 
}

其中「name」是錯誤的類型（相應的構造方法的名稱，如「錯誤」，「的SyntaxError」等。）。在你的例子中，你可以使用名字「AuthentificationError」。

來源

2012-08-05 16:57:02

這是正確的，但JavaScript中的錯誤與例如。數組，而表示錯誤的JSON對象與表示例如的對象無法區分。用戶數據。我相信你應該將你的對象嵌套在根對象的「錯誤」屬性中。通過這種方式，您不僅可以根據HTTP代碼區分成功數據的錯誤。 – Tadeck 2012-08-05 17:04:14

@Tadeck我不認爲這是必要的，因爲OP在向客戶端發送錯誤時設置了4xx狀態碼。狀態碼可以作爲響應對象的'.status'屬性。 – 2012-08-05 17:07:16

很棒的評論@Tadeck。所以你會建議像{'錯誤'：{'name'：'...'，'message'：'...'}}？ – used2could 2012-08-05 17:07:41

嘗試對您發送的錯誤稍微詳細一點。這種結構已建議在一些地方給予足夠的信息，既爲用戶和開發者使用API

"error":{ 
     "code":"410", 
     "long":"410001", 
     "message":"cannot connect to DB", 
     "developer":"Connection to the DB was unsuccessful due to ...", 
     "documentation": "mysite.com/help/errors/..." 
    }

返回錯誤正確的HTTP代碼。錯誤地返回代碼200是不好的做法。
擴展的代碼與自己的錯誤ID
提供能夠大致勾勒出了錯誤的原因的短消息。考慮爲開發者添加更詳細的消息。請記住，API錯誤消息是開發人員閱讀時間的99.9％，因此通過提供技術細節（在合理範圍內）讓他們開心，以便他們能夠儘快解決問題。
如果您保留有關您的api和錯誤代碼的公開文檔，只需添加url。

來源

2013-11-29 02:24:05 swogger

例外的建議JSON結構？

回答

相關問題