常見的 API 錯誤以及如何修復它們

在構建任何軟件時，無論是網站還是應用程序，都必須將質量保證納入您的軟件開發週期。如果錯過了，很有可能會發布錯誤的實例，這肯定會破壞最終用戶的體驗。

沒有任何利益相關者希望這種情況發生。這就是為什麼測試對成功發布保持警惕並確保對您添加的功能的積極響應。這需要最常見的用例場景來驗證流程是否按預期工作，然後您的任何真實客戶都有機會檢查它。

在考慮在您的覆蓋套件中包含哪些測試時，請注意 API 測試，因為它是最重要和最廣泛使用的類型之一。API（應用程序編程接口）存在於任何應用程序中，並負責多個軟件系統之間的正確通信。API 的主要功能包括指定可以傳輸的數據請求以及處理這些請求的條件。 

例如，用戶想要將一些商品添加到購物車，按下觸發 API 請求的相應按鈕，接收響應，然後更新購物車。如果此請求失敗，“添加到購物車”功能將中斷。

這就是 API 問題如何影響業務，增加了一個更重要的因素，為什麼每個人都應該正確測試它。要合併此測試，應該從正確的自動化API 測試工具開始，以確保不會漏掉任何錯誤。

可能有不同的 API 錯誤，在這裡我們將告訴您更多關於 5 個最流行的錯誤： 

不正確的 HTTP 方法

最簡單但廣泛傳播的 API 錯誤是不正確的 HTTP 方法。通常，該問題是由文檔中的空白引起的。示例之一可能是發送指定數據選項的 GET 請求，但跳過提及 -X GET 參數。結果，它會自動轉換為 POST 請求。此外，在切換 API 工具時可能會出現 HTTP 方法的問題，因為其中一些可能使用一種方法來創建和修改測試環境，而另一些則使用不同的方法來執行這些操作。這就是為什麼仔細檢查這些細微差別以及採用一致的方法來編寫自己的文檔很重要的原因。 

使用錯誤的協議

另一個常見錯誤是 https:// 和 http:// 協議之間的差異。有些 API 可能只支持其中一種協議，比如 http，因此在這種情況下指定 https:// 會導致請求處理不正確。即使它們都受支持，當您指定 http:// 時，重定向到 https:// 也可能存在問題。當您計劃使用的第三方 API 的提供者進行一些更改並且未能發送相關通知時，也可能會發生這種情況。所以最好不時重新檢查這些方面。要創建自己的 API，最好使用 https:// 協議。為此，需要安裝 SSL 證書給主人。前段時間，SSL 證書的成本有點高，因此可能會有疑問，但有了 Letsencrypt 或 Cloudflare 等免費提供商，它變得比以往任何時候都容易。

沒有有意義的錯誤信息

如果您曾經遇到過“意外的 API 錯誤””，你知道這可能有多煩人。通常，錯誤消息應該有助於開發人員進行故障排除，指出錯誤的確切原因或至少在哪裡搜索它。不幸的是，這種無信息的錯誤可能會導致數小時的浪費時間，增加解決錯誤所需的時間，從而導致您收到的負面反饋出現更大的峰值，這就是為什麼最好花更多時間來描述潛在的錯誤並使消息為那些需要對其進行故障排除的人提供信息。雖然存在幾十個 HTTP 錯誤代碼，但不需要全部使用，但保留標準錯誤代碼（200,400 和 500）並考慮將提示包含在消息中，以便即使在某些情況下不起作用，

授權麻煩

看起來這裡一切都清楚了，因為錯誤的授權通常會假定用戶名或密碼不正確，但實際上，即使將標題中的“授權”與“身份驗證”混淆也會導致錯誤。它在使用 OAuth 2 協議時尤其有效。此外，語法很重要，因為一些簡單但不太明顯的事情會造成混亂。在大多數情況下，這些是不記名令牌，“Basic”前綴中的空格，缺少完整添加此前綴，以及“用戶名：密碼”對中的冒號丟失。即使在某些不需要密碼的 API 中單獨使用用戶名，您仍然需要使用該冒號。

未能指定 Content-Type 和 Accept 標頭

一些 API 可以容忍頭部不包含 Content-Type 或 Accept 頭部但對應於允許的數據格式的請求。其他人則比較謹慎，不會讓請求通過發出 403 Permission Denied 錯誤代碼。在這個階段，客戶端和服務器之間關於請求和響應中預期的數據類型的交互已經建立。實施此標頭檢查是為了降低安全漏洞和整體黑客攻擊的風險，這就是為什麼最好指定這些標頭以避免在使用過程中出現任何問題。

包起來

執行 API 測試以及其他測試類型，包括回歸、冒煙測試，當然還有開發衝刺期間的單元測試，將有助於您的軟件發布更快。它背後的邏輯很簡單：越早發現錯誤、缺陷或與業務需求的不一致，就越容易修復它。因此，為您的最終用戶提供一流的體驗，他們將能夠享受與您的軟件的交互，並且在此過程中不會出現意外錯誤，從而為您的業務帶來更多利潤。