實現介面的可控，有記錄，對介面邏輯徹底審查，避免漏洞。
所有資訊系統之間資料非人工互動的功能或工具。
接**術負責人負責編寫文件或**商編寫，技術負責人對文件負責；
業務相關負責人負責對介面資料審查；
專案經理對介面為主體責任人。
4.2 介面開發前需充分論證，並消除風險。對低風險內容如果無法消除，必須在介面文件中明文說明，並有應對方法和策略。
4.3 介面資料，需有指定崗位進行一致性檢查，並週期進行。定崗週期檢查及檢查方法規定到介面文件中。
4.4 介面文件，涉及到的部門需簽署。資訊部門有義務向涉及部門解釋清楚其中邏輯和優缺點風險項。
4.5 介面文件中，必須有資料流程圖，對映字段，介面實現方法。關鍵**需出現在文件中。
4.6 介面文件中，需考慮【增，刪，改，查，關聯資訊】等幾種業務場景。如某業務場景無關，也需明文寫上：刪除資料，介面無關。
4.7 介面文件由技術人員編寫，業務干係部門負責人審查簽署，專案經理簽字後生效執行。
4.8 開發型系統，介面條件需寫為可配置式或系統介面執行**方法，不得只寫於底層**中。
4.9 針對系統，統一文件，編撰為介面手冊，儲存在wiki中供查詢查閱。
4.10 介面變更，需更新介面文件，在原發行文件內容後附加：變更原因，變更目的，變更邏輯，歷史資料處理，業務影響等內容。
4.11 介面開發完成後，需經【其它技術人員審查**》業務人員審查業務邏輯》技術人員資料測試》需求部門資料測試》關聯部門資料審查》專案經理批准】過程，方可正式部署和使用。過程均記錄到介面文件中。
由監督組對進行中的介面按照以上介面文件和內容要求進行審查。
5.1 審查文件內容合規性；
5.2 審查系統資料是否符合文件的業務邏輯。
5.3 對未識別的bug和邏輯漏洞，視情況和情節對以上責任人進行處理。
介面規範 API介面
同通過網路，規定前後臺資訊互動規則的url連線，是前後臺資訊互動的媒介。1 url 2 請求方式 get post put patch delete 3 請求引數 json或xml格式的key value型別資料 4 響應結果 json或者xml格式的資料 編寫介面文件可以使用去哪網技術中心的乙個開...
使用者介面規範
最好的程式介面就是使用者無需去閱讀操作手冊就知道該如何使用的介面。原則1.一致性如果你可以在乙個列表的專案上雙擊後能夠彈出對話方塊，那麼應該在任何列表中雙擊都能彈出對話方塊。要有統一的字型寫號 統一的色調 統一的提示用詞 視窗在統一的位置 按鈕也在視窗的相同的位置。2.設定標準並遵循它可以引數一些工...
RESTful api介面規範
整體規範建議採用restful 方式來實施。協議api與使用者的通訊協議，總是使用https協議，確保互動資料的傳輸安全。網域名稱應該盡量將api部署在專用網域名稱之下。如果確定api很簡單，不會有進一步擴充套件，可以考慮放在主網域名稱下。api版本控制 應該將api的版本號放入url。v 另一種做...