設計標準的API是一項很困難的任務,包含有很多主觀指標,即使是一家完全接受RESTful API設計原則并對其問題空間有完整看法的小型初創公司,最終也可能會出現命名不一致、介面模糊和語意不規范的情況,當一個擁有許多不同開發團隊的大型組織以一種特殊的方式面對這些相同的挑戰時,其影響是復雜的,并常常導致API產生隔閡,使它們難以從中脫穎而出,在本文中,我將討論三種可幫助您的企業API避免這些隔閡的實踐,
正確理解語意
最重要的是要正確的語意,正確的語意指的是API端點和查詢字串引數的命名、傳遞的資料結構的布局、HTTP報頭的使用以及有關回傳HTTP狀態代碼的約定,不同的設計師經常從完全不同的角度解釋RESTful介面的基本原理,并且解釋最終變得非常主觀,在端點的命名以及引數和資料結構的使用中最為明顯,
API端點名稱是用戶遇到的API中最明顯的方面,與任何其他特性相比,更能向用戶傳達有關RESTful API設計的資訊,無論端點是為資源(客戶),流程(清單)還是介質(移動設備)命名的,如果在問題空間和業務中使用一致地約定,API將會更加易于理解,在大型企業中,要達到這種一致性水平的唯一方法是要制定嚴格的規定,并在所有開發團隊中應用這些規定,
除了API端點命名之外,還存在命名引數和資料結構的問題,不同的介面將具有不同的資料需求,但這里也應該采用和使用樣式約定,如果使用“ OneAPIDoesThis”和“another_does_this”,那么這些API放在一起就不那么容易理解了,同樣的情況適用于通用引數或通用資料結構,如果兩個端點都使用了Access Token,那么它們使用相同的名稱通常會更好,
發現和檔案
即使擁有良好的RESTful API設計和一致的應用約定,但是如果用戶不能輕松了解這些設計功能并探索使用不同端點的方式,那么它們對用戶幾乎沒有好處,在設計新的API或記錄API可以使用API管理工具,工具可以幫助我們定義端點作為模型型別回傳的資料結構,記錄欄位,無論它們是必需的還是可選的,以及值范圍和約束,這節省了大量的作業,并且非常保證您的代碼在有效的輸入上運行,
訪問和可測驗性
用戶在使用新API時遇到的早期障礙之一就是弄清楚它的作業原理,無論端點的名稱,或者檔案的可用性如何,大多數開發人員都需要在新客戶端的早期開發程序中測驗API,我最喜歡的API測驗工具是名為Eolinker:www.eolinker.com,Eolinker允許定義端點的命名集合,以及執行每個端點所需的URL,請求引數,報頭和主體資料,定義后,只需單擊即可執行端點,并報告呼叫的性能,以及訪問有關回應的詳細資訊,另外Eolinker還可以匯入Swagger規范并為您生成API,

當然,在開發新的API時,還有許多其他重要的設計和實作考慮,其中最有影響的是你如何決定對它進行版本控制,目前而言,我相信遵循以上概述的做法可以幫助您創建整個業務中保持一致的API,這些API可由用戶發現并按需進行檔案化,并且可由客戶端開發人員輕松測驗的API,總而言之,這是三種有助于避免企業API管理混亂的方法,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/256617.html
標籤:其他
