開(kāi)發(fā)API接口需要哪些知識(shí)？
個(gè)人一直從事Java服務(wù)端開(kāi)發(fā)，如今已經(jīng)是移動(dòng)端的天下，幾乎每一個(gè)C端的項(xiàng)目應(yīng)該都是前后端分離的，或APP native開(kāi)發(fā)，或H5 web開(kāi)發(fā)，小程序、公眾號(hào)開(kāi)發(fā)，這些基本都是前后端分離的項(xiàng)目，也就是需要服務(wù)端同學(xué)開(kāi)發(fā)API即可，不需要關(guān)心前端相關(guān)技術(shù)棧了，也可以說(shuō)是技術(shù)工種的再一次細(xì)分。
那么作為一個(gè)服務(wù)端開(kāi)發(fā)人員，開(kāi)發(fā)API接口需要哪些知識(shí)呢？個(gè)人覺(jué)得可以從兩個(gè)角度來(lái)看：
自己公司產(chǎn)品開(kāi)發(fā)API
給第三方開(kāi)發(fā)API，也叫OpenAPI、開(kāi)放API，很多大公司都有自己的開(kāi)放平臺(tái)
個(gè)人認(rèn)為只有開(kāi)發(fā)好了自己公司的API，才有資格或者有能力開(kāi)發(fā)好開(kāi)放API！
那么從開(kāi)發(fā)自己公司API開(kāi)式，個(gè)人覺(jué)得需要以下知識(shí)點(diǎn)：
響應(yīng)時(shí)間要快“天下武功，唯快不破”，一個(gè)好的API接口響應(yīng)時(shí)間一定要快，多快算快？沒(méi)有最快，只有更快！一般公司會(huì)要求所有API響應(yīng)時(shí)間不得超過(guò)100ms，高并發(fā)API再單獨(dú)要求，例如不得超過(guò)40ms，且吞吐量超過(guò)3000tps！
返回的數(shù)據(jù)格式要穩(wěn)定相信做過(guò)API開(kāi)發(fā)的同學(xué)一定有經(jīng)驗(yàn)，由于序列化方式的不同，有時(shí)候一個(gè)字段沒(méi)有值的時(shí)候可能會(huì)返回如下三種情況：
這個(gè)字段在返回的json串里沒(méi)有了；
這個(gè)字段返回的是一個(gè)null；
這個(gè)字段返回的是一個(gè)空字符串。
如果你是前端的話，每個(gè)接口規(guī)則都不一樣，你頭大不大？是不是代碼里到處都充斥著
if(id && id != null && id != "")這樣的判斷代碼？一不小心忘記處理了，然后APP的奔潰率就上來(lái)了。
文檔要清晰標(biāo)準(zhǔn)一個(gè)好的API一定要有一個(gè)好的文檔，API是靈魂的話，文檔就是肉體以及華麗的外表，每一次對(duì)接口的更新都要及時(shí)反饋到文檔上去并且及時(shí)的告知前端開(kāi)發(fā)人員。我平時(shí)常用的就是把API文檔寫(xiě)在wiki上，固定好一個(gè)API文檔模板，大家都按照這個(gè)規(guī)則去寫(xiě)就好了，這樣前后端聯(lián)調(diào)時(shí)候?qū)φ涨逦奈臋n也會(huì)省去很多的溝通成本。切不可因?yàn)閼械脤?xiě)文檔，覺(jué)得聯(lián)調(diào)時(shí)候溝通充分就可以了。你要知道隨著時(shí)間的推移，這個(gè)API很可能就被你忘了，或者接手的同事也無(wú)從下手。所以一定要有一個(gè)清晰的文檔！
那么在此基礎(chǔ)上如何開(kāi)發(fā)一個(gè)優(yōu)秀的開(kāi)放API呢？個(gè)人認(rèn)為這個(gè)大家其實(shí)都知道怎么一回事，因?yàn)榧词鼓銢](méi)寫(xiě)過(guò)openAPI，你還沒(méi)調(diào)用過(guò)openAPI嗎？微信支付、支付寶支付、極光推送、IM、友盟、OCPC、客服等等第三方應(yīng)用都需要咱們調(diào)用他們的API，看過(guò)別人怎么玩的，咱自己照抄就好了。還有一點(diǎn)想要說(shuō)的就是：“把握好自己的需求，千萬(wàn)不要過(guò)度設(shè)計(jì)！”
這里沒(méi)有說(shuō)具體的技術(shù)，實(shí)際上把以上工作做好了，關(guān)于技術(shù)這些自然也就好了，細(xì)節(jié)注定成敗，大家認(rèn)為開(kāi)發(fā)一個(gè)好的API最重要的事情是什么？歡迎評(píng)論區(qū)留言討論~
我是【java架構(gòu)設(shè)計(jì)】，關(guān)注我，持續(xù)為您提供優(yōu)質(zhì)內(nèi)容！