增強的錯誤碼 enhanced-error-codes
概觀 overview
本檔案說明API錯誤代碼清單，以及傳回給應用程式的其他錯誤資訊。
若要在程式設計人員應用程式中使用增強型錯誤代碼，需要向支援團隊提出請求，才能在設定變更時啟用它。
回應錯誤處理 response-error-handling
在大多數情況下，Primetime驗證API會在回應本文中包含其他錯誤資訊，以便提供 有意義的上下文 發生特定錯誤的原因和/或自動修正問題的可能解決方案。 但是，在涉及驗證或登出流程的特定情況下，Primetime驗證服務可能會傳回HTML回應或空白內文 — 請檢視API檔案以取得詳細資訊。
雖然某些型別的錯誤可以自動處理（例如，在網路逾時的情況下重試授權請求，或在其工作階段過期時要求使用者重新驗證），但其他型別可能需要設定變更或客戶服務團隊互動。 在這種情況下，程式設計師必須收集並提供完整的錯誤資訊。
Primetime驗證API會傳回400至500範圍內的HTTP狀態程式碼，以指出失敗或錯誤。 每個HTTP狀態程式碼都有特定的含意：
-
4xx錯誤代碼表示錯誤是由使用者端產生的，使用者端需要執行額外的操作來修正錯誤（例如，在叫用受保護的API或提供任何必要的引數之前取得存取權杖）
-
5xx錯誤碼表示錯誤是由伺服器產生的，伺服器需要執行額外的作業來修正。
其他錯誤資訊包含在回應本文的「error」欄位中。
{
"status" ：403，
"code" ： "network_connection_failure"，
"message" ："Unable to contact your TV provider services"，
"helpUrl" ： ""，
"trace" ： "12f6fef9-d2e0-422b-a9d7-60d799abe353"，
"action" ： "retry"
}
----------------------------------------------------------------------------
XML
< error >< status >403</ status >< code >network_connection_failure</ code >< message >Unable to contact your TV provider services</ message > < helpUrl ></ helpUrl >< trace >12f6fef9-d2e0-422b-a9d7-60d799abe353</ trace >< action >retry</ action ></ error >處理多個專案的Adobe Primetime API （預先授權API等）可能會使用專案層級錯誤資訊，指出處理特定專案是否失敗，以及其他專案是否成功。 在此案例中， "error" 物件位於專案層級，且回應本文可能包含多個 "errors" 物件 — 請參閱API檔案。
JSON
{
"id" ： "TestStream1"，
"authorized" ： true
}，
{
"id" ： "TestStream2"，
"authorized" ： false，
"error" ： {
"status" ：403，
"code" ： "network_connection_failure"，
"message" ："Unable to contact your TV provider services"，
"details" ： ""，
"helpUrl" ： ""，
"trace" ： "8bcb17f9-b172-47d2-86d9-3eb146eba85e"，
"action" ： "retry"
}
}
]
}
每個錯誤物件都有以下引數：
- 400個錯誤請求
- 400個錯誤請求
- 400個錯誤請求
- 401未獲授權
- 403禁止
- 404找不到
- 405不允許的方法
- 409衝突
- 410已過期
- 412先決條件失敗
- 429太多請求
- 500間隔伺服器錯誤
- 503服務無法使用
請注意，如果未從合作夥伴服務收到自訂訊息，則錯誤欄位中可能不存在此欄位。
URI代表絕對URL，不應從錯誤代碼推斷。 根據錯誤內容，可以提供不同的url。 例如，相同的bad_request錯誤碼將會為驗證和授權服務產生不同的url。
-none — 很抱歉，沒有預先定義的動作來修正此問題。 這可能表示對公用API的呼叫不正確
-configuration — 需要透過TVE儀表板或連絡支援人員來變更設定。
-application-registration — 應用程式必須重新登入本身。
-authentication — 使用者必須驗證或重新驗證。
-authorization — 使用者必須取得特定資源的授權。
-degradation — 應該套用某種形式的降級。
-retry — 重試請求或許可以解決問題
-retry-after — 在指定的時間段後重試請求可能會解決問題。
附註：
-
受限制 欄 指示個別欄位值是否代表有限集 (例如「」的現有HTTP狀態代碼 狀態「 」欄位)。 此規格的未來更新可能會將值新增至限制清單，但不會移除或變更現有值。 不受限制的欄位通常可以包含任何資料，但為確保合理的大小，可能有一些限制。
-
每個Adobe回應將包含「Adobe — 請求 — ID」，用於識別整個HTTP服務中的使用者端請求。 「trace「欄位是對和的補充，應該一起報告。
HTTP狀態碼和錯誤代碼 http-status-codes-and-error-codes
各種錯誤碼與其相關HTTP狀態碼之間的不一致性，是因為與舊版sdk和應用程式(例如 未知_application 產生400個錯誤請求，當 未知_software_statement 產生401 （未獲授權）。 解決這些不一致將在未來的反複專案中成為目標。
動作和錯誤代碼 actions-and-error-codes
對於大多數的錯誤碼，多個動作可能符合資格作為修正手頭問題的路徑，或者甚至可能需要多個動作才能自動修正它們。 我們選擇指出修正錯誤的可能性最高的錯誤。 此 動作 可分為三個類別：
- 嘗試修正請求內容的請求（重試、之後重試）
- 嘗試修正應用程式內的使用者內容（應用程式註冊、驗證、授權）的使用者內容
- 嘗試修正應用程式和身分提供者之間的整合內容（設定、效能降低）的訪客
對於第一個類別（重試和之後重試），僅重試相同請求可能足以解決問題。 如果API處理多個專案，應用程式應重複該請求，並僅包含具有「重試」或「在此之後重試」動作的專案。 針對"之後重試「動作，a 」於以下時間後重試「標題會指出應用程式在重複要求前應該等待的秒數。
對於第2和第3個類別，實際動作實作高度取決於應用程式功能。 例如，「退化「可實作為」切換至15分鐘暫時通路以允許使用者播放內容「或實作為」自動工具套用AUTHN-ALL或AUTHZ-ALL降級以便與指定MVPD整合」。 類似於「authentication「動作可能會在平板電腦上觸發被動驗證（背景通道驗證），並在連線的電視上觸發完整的第二熒幕驗證流程。 這就是為什麼我們選擇提供包含結構描述和所有引數的完整URL。
錯誤代碼 error-codes
下列錯誤表列出了可能的錯誤代碼、相關訊息和可能的動作。