本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

Amazon S3 錯誤的最佳實務

許多錯誤回應包含額外的結構化資料，負責診斷程式設計錯誤的開發人員應詳加閱讀及了解。例如，若您傳送之 REST PUT 要求中所包含的 Content-MD5 標頭，不符合伺服器計算所得的摘要，您就會收到 BadDigest 錯誤。錯誤回應也包含 作為計算摘要的詳細元素，以及您提供的預期摘要。您可以在開發時使用此資訊診斷錯誤。在生產環境中，一支運作良好的程式可能將此資訊包含在其錯誤日誌中。

當您設計可與 Amazon S3 搭配使用的應用程式時，正確處理 Amazon S3 錯誤十分重要。本節說明設計應用程式時須考量的問題。

重試 InternalError

內部錯誤是指 Amazon S3 環境內發生的錯誤。

收到 InternalError 回應的要求可能尚未處理。例如，若 PUT 要求傳回 InternalError，後續的 GET 可能會擷取舊值，也可能會擷取更新後的值。

若 Amazon S3 傳回 InternalError 回應，請重試該請求。

針對重複出現的 SlowDown 錯誤微調應用程式

一如所有的分散式系統，S3 也設有保護機制，可以偵測有意或無意的資源過度使用，同時採取相應的回應。當要求率觸發其中一項機制時，即會產生 SlowDown 錯誤。降低要求率即可減少或消除此類型的錯誤。一般而言，大多數使用者不會定期遇到這些錯誤；不過，如果您想要更多資訊，或遇到高或非預期的 SlowDown 錯誤，請張貼到我們的 Amazon S3 開發人員論壇或註冊 支援 https://aws.amazon.com/premiumsupport/。

隔離錯誤

Amazon S3 提供一組錯誤代碼供 SOAP 與 REST API 使用。SOAP API 會傳回標準的 Amazon S3 錯誤代碼。REST API 的設計類似標準的 HTTP 伺服器，會與現有的 HTTP 用戶端 (例如瀏覽器、HTTP 用戶端程式庫、代理伺服器、快取等等) 互動。為了確保 HTTP 用戶端正確處理錯誤，Amazon S3 會將每個 Amazon S3 錯誤對應至 HTTP 狀態碼。

HTTP 狀態碼不如 Amazon S3 錯誤碼易懂，而且包含的錯誤資訊也較少。例如 NoSuchKey 及 NoSuchBucket 兩個 Amazon S3 錯誤都可對應到 HTTP 404 Not Found 狀態碼。

雖然 HTTP 狀態碼包含的錯誤資訊較少，但了解 HTTP 卻不了解 Amazon S3 API 的用戶端，通常都能正確處理錯誤。

因此在處理錯誤或將 Amazon S3 錯誤回報給使用者時，會使用 Amazon S3 錯誤代碼，而不會使用 HTTP 狀態碼，因為前者包含了大部分的錯誤資訊。此外，在對應用程式執行除錯時，您也應該參考 XML 錯誤回應之 <Details> 元素中可供人閱讀的內容。