隨著低代碼和無代碼工具的出現，構建API比以往任何時候都更簡單、更快，不過因為開發簡單了，開發者很容易忽略一些潛在的問題，導致整個業務的下游影響，
在設計階段多花點時間，可以確保API真正有用、安全、可擴展和穩定，
本文會討論API開發者需要避免的10個常見錯誤，幫助我們開發更高質量的API，
API開發者需要避免的10個常見錯誤
1、API開發者的錯誤導致臃腫的回應
從撰寫代碼的角度來看，呼叫回傳整個物件，比回傳特定的引數要容易得多，但問題是這種呼叫造成的問題大于其帶來的價值，這些臃腫的回應引數對使用者毫無意義，還會影響兩端的延遲和帶寬，
所以需要在方法中建立靈活性，讓使用者可以自由選擇，是回傳完整物件，或者所需的特定引數，
** 2、多個場景隔離呼叫**
單獨的測驗單個方法僅對單元測驗有用，但這并不能保證同樣的方法也能在應用生態系統中發揮作用，我們可以在單元測驗中獲得積極的結果，但在實際使用測驗中會遇到錯誤，為避免此問題，我們需要在多個場景中運行每種方法，以確保效果，
3、不了解需要解決的問題
當需求與開發人員認為的問題之間存在脫節時，問題肯定會出現，這種不幸但常見的錯誤會讓使用者失望，也會浪費我們的時間去返工重做，為了避免這個問題，需要評估整個作業流程以了解它是如何適應的，
4、API開發者的錯誤導致耗時的故障排除
當錯誤訊息提示對消費者沒有意義時，它會在兩端造成不必要的作業，消費者必須花費數小時來解決問題，到最后，我們也不得不幫助他們，并最終進行一些返工以創建更有用的錯誤訊息提示，我們需要通過準確地解釋每一個錯誤的含義和出錯的地方來創建有用的錯誤訊息提示，此外，堅持使用眾所周知的狀態代碼，
5、忽略可擴展性
隨著時間的推移、使用量的增加，對系統提出了更高的要求，應用程式編程介面需要適當地處理需求和擴展，在設計階段規劃可擴展性可以幫助避免這個問題，
6、缺少幫助檔案
當缺少幫助檔案時，沒人會深入使用我們新開發的應用程式編程介面，此問題會導致滿意度降低和無休止的故障排除，提供解釋如何使用API的綜合幫助檔案，確保檔案保持最新；這讓使用者知道如何使用任何功能，
7、輸入驗證不足
當我們沒有在資料驗證上花費足夠的時間時，總會有人發現導致問題的漏洞，它可以簡單到在看似無害的欄位中傳遞無效資料，花點時間驗證使用者發送的每個輸入，以最小化發生這種情況的機會，
8、高輪詢請求處理不當
尋找最新資料的使用者高頻提出請求，容易給系統帶來不必要的壓力，與其讓客戶請求更新，不如使用webhooks之類的框架，在資料發生變化時推送更新的資料，這可以減少不必要的輪詢，
9、冗余端點
冗余端點是支持和重構的噩夢，當多個端點回傳相同的資料時，就會發生這種API開發的錯誤，因為我們需要對參考該資料的所有端點進行更新，在實施新端點以支持各種用例時，請密切關注更新，確保沒有端點包含可能會重復使用的相同資訊，
10、沒有針對性能進行優化
發送多個請求來完成一項任務會導致延遲和帶寬開銷，我們可以通過將這些小請求批量處理為一次呼叫來優化性能，這些批量的處理請求對于想要為同一行程發送大量請求的使用者非常有用，
使用 Eolink 創建功能齊全的API
開發健全的、可擴展且有用的API并不一定很復雜，如果我們遵循一些額外的步驟并避免這 10 個容易出現的API開發錯誤，就可以最大限度地減少返工并創建一個提供大量價值的全功能 API，除此之外，使用Eolink這類可視化的API開發工具，也可以幫助我們快速輕松地構建 API，
圖中所使用的的介面管理工具是eolink，可以對不同型別的介面進行測驗，在測驗流程中也支持添加不同步驟，感興趣可以自行使用：www.eolink.com
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/451288.html
標籤：其他