隨著業務的發展,支撐組的專案也是越來越多。同時,從整個支撐組專案架構體系(含運維和運營體系),我們對系統業務水平拆分,垂直分層,讓業務系統更加清晰,產生了一系列平台和子系統,並使用介面進行資料互動。伴隨著業務的發展,介面營運而生,並且會越來越多。
我們運營和維護著諸多的對外介面,很多現有的介面服務寄宿在各個不同的專案,哪些應用在使用api也沒有管理起來。並且以前的呼叫模式也是比較複雜,排錯困難。
工作中也有合作開發的同事多次強力要求給出api文件,特別是每個開發組都來要一次,往往解釋半天,大家也很痛苦。那麼,讓不開的問題是,如何管理和維護這些api,才能讓大家都輕鬆?沒有集中的的api專案
**和文件不匹配
文件不規範
api不規範
擼碼一分鐘,對接三小時uri請求協議
請求方式
頭部(系統引數)
請求引數(業務)
響應引數(業務)
返回示例
定義返貨結果資料結構,更直觀目前已經歸檔的專案
目前已經歸檔的專案api
專案中使用restfulapi的情況較多,webservice,wcf,webapi均支援，所以這裡該規範重點針對resfulapi。
有了規範更能減少溝通誤差,提高工作效率
如何寫好軟體文件
今天看到一篇介紹寫作技術文件的文章，試著翻譯了一下，翻得不好，請大家幫忙改正。正文如下 我不知道是不是有人會將閱讀或書寫技術文件當 好。雖然很討厭這樣做，但是通常為了解決問題或介紹乙個技術產品，我們不得不去做這些事情。要想寫好文件很難。技術文件有幾種形式 基本概覽，高階概覽，一步一步的演示，自動生成...
如何寫好需求文件
需求文件可能是很多產品的學習第一課，到底怎麼寫好乙份需求文件，還是要追根溯源從根本上說起 本著萬物可追溯，萬物可分解的原則，這個問題可以分解成三個問題 1 不寫行不行 推動需求落地的一般來說需要以下幾個步驟 1 前期溝通 2 宣講 3 原型 文件 4 後續溝通 所以原型 需求文件在整個落地過程中處於...
產品經理如何寫好產品文件
作為網際網路公司的pm 產品經理 我們需要面對眾多部門，因為自己就是項鍊裡的那根線。需要書寫各種文件，最常見的就是prd 產品需求文件 當然根據重量級和時間等多因素，可以提交不同類別的，例如drd 設計需求文件 和erd 工程需求文件 嘿嘿，drd和erd是我自己發明的。更多小的ecr級別專案中，文...