4個(gè)要點(diǎn),編寫一份接口需求文檔

54 評(píng)論 62891 瀏覽 701 收藏 11 分鐘

在產(chǎn)品設(shè)計(jì)工作中,或多或少都會(huì)需要用到接口,特別是業(yè)務(wù)導(dǎo)向性的系統(tǒng),接口幾乎是必不可少的功能。那么什么是接口?如何寫一份能準(zhǔn)確表達(dá)業(yè)務(wù)需求的接口需求文檔呢?

一、什么是接口

百科上對(duì)接口的定義:API(Application Programming Interface,應(yīng)用程序編程接口)是一些預(yù)先定義的函數(shù),目的是提供應(yīng)用程序與開發(fā)人員基于某軟件或硬件得以訪問一組例程的能力,而又無需訪問源碼,或理解內(nèi)部工作機(jī)制的細(xì)節(jié)。

要理解接口是什么,首先理解一下為什么要用接口?

兩個(gè)獨(dú)立的系統(tǒng),它們的數(shù)據(jù)或程序是獨(dú)立的,這就使得它們無法直接訪問對(duì)方的數(shù)據(jù)庫或程序(兩個(gè)獨(dú)立的數(shù)據(jù)相當(dāng)于兩個(gè)獨(dú)立的家庭,每個(gè)家庭肯定是不允許外人隨便進(jìn)入的,否則會(huì)發(fā)生偷竊等后果嚴(yán)重的事件)。但是某些業(yè)務(wù)場(chǎng)景下,獨(dú)立的系統(tǒng)之間又必須相互共享數(shù)據(jù)或共用一套程序邏輯,如統(tǒng)一業(yè)務(wù)流程上的不同業(yè)務(wù)操作系統(tǒng),下游系統(tǒng)的業(yè)務(wù)依賴于上游系統(tǒng)的數(shù)據(jù)。

既然如此為什么不把它們?cè)O(shè)計(jì)成一個(gè)系統(tǒng),這樣不就沒有上面的問題了嗎?

這是因?yàn)橛械臉I(yè)務(wù)流程很長(zhǎng)很復(fù)雜,如果設(shè)計(jì)成一個(gè)系統(tǒng),整個(gè)系統(tǒng)變得很龐雜,不論是功能設(shè)計(jì)、開發(fā)維護(hù)都很難。因此一般都會(huì)把雖然有上下游業(yè)務(wù)關(guān)系但又有清晰邊界的業(yè)務(wù)劃分成獨(dú)立的系統(tǒng)實(shí)現(xiàn),如采購系統(tǒng)和倉儲(chǔ)系統(tǒng)。此外,很多時(shí)候我們需要獲取的數(shù)據(jù)是我們外部其他公司擁有的數(shù)據(jù),更不可能設(shè)計(jì)成同一個(gè)系統(tǒng)了。

基于以上兩點(diǎn):接口就是兩個(gè)獨(dú)立系統(tǒng)之間同步數(shù)據(jù)或訪問對(duì)方程序的途徑。

二、如何設(shè)計(jì)接口

1. 搞清楚是主動(dòng)訪問還是被動(dòng)請(qǐng)求:

a. 若是主動(dòng)訪問,有兩種情況:

一是我方是數(shù)據(jù)的使用方,需要主動(dòng)從對(duì)方獲取數(shù)據(jù);二是我方是數(shù)據(jù)的提供方,需要主動(dòng)將數(shù)據(jù)同步給對(duì)方。

主動(dòng)訪問時(shí)無需做接口,而是訪問對(duì)方的接口,要搞清楚的問題是:我們需要在什么節(jié)點(diǎn)訪問對(duì)方的接口?是用戶觸發(fā)某個(gè)操作的時(shí)候?qū)崟r(shí)去訪問?還是沒有實(shí)時(shí)性要求,只是周期性地訪問?

若我方是數(shù)據(jù)的使用方且需要的數(shù)據(jù)是用戶使用某個(gè)功能必須的數(shù)據(jù),因此必須在用戶操作時(shí)實(shí)時(shí)去訪問對(duì)方的接口獲取數(shù)據(jù)并展示給用戶,典型的有我們注冊(cè)某網(wǎng)站時(shí)獲取驗(yàn)證碼的功能。

若我方是數(shù)據(jù)的使用方且需要的數(shù)據(jù)是一些跟用戶實(shí)時(shí)操作無關(guān)的基礎(chǔ)數(shù)據(jù),如客服系統(tǒng)需要從其他業(yè)務(wù)系統(tǒng)獲取用戶的基礎(chǔ)數(shù)據(jù),以在系統(tǒng)中的某些功能下展示用戶的信息(如客服在處理客訴等問題時(shí),需要知道客戶的一些詳細(xì)信息,這些信息只有業(yè)務(wù)系統(tǒng)有)。這種情況下,一般會(huì)新增一個(gè)腳本定時(shí)(如兩小時(shí)一次)訪問對(duì)方的接口將數(shù)據(jù)獲取過來存儲(chǔ)到自己的數(shù)據(jù)庫,在用到的時(shí)候直接從自己數(shù)據(jù)庫獲取并展示。

若我方是數(shù)據(jù)的提供方且提供的數(shù)據(jù)是下游系統(tǒng)需要的實(shí)時(shí)要求高的數(shù)據(jù)則更多地用實(shí)時(shí)同步;若是基礎(chǔ)數(shù)據(jù),則選擇周期性同步的方式。

b. 若是被動(dòng)請(qǐng)求,有兩種情況:

一是我方是數(shù)據(jù)提供方,需要對(duì)方來獲取數(shù)據(jù);二是我方是數(shù)據(jù)使用方,需要對(duì)方主動(dòng)將數(shù)據(jù)同步過來。

被動(dòng)請(qǐng)求需要提供接口供對(duì)方訪問,此時(shí)要搞清楚:讓對(duì)方來訪問的時(shí)候,需要提供什么樣的參數(shù)?根據(jù)他提供的參數(shù)我們需要返回什么數(shù)據(jù)?這些數(shù)據(jù)從哪里取值?

若有一些數(shù)據(jù)的來源是本系統(tǒng),其他系統(tǒng)需要使用這些數(shù)據(jù),則可提供接口讓其他系統(tǒng)通過訪問接口獲取這些數(shù)據(jù)。

若我方是數(shù)據(jù)使用方且讓對(duì)方將數(shù)據(jù)主動(dòng)同步過來,此種場(chǎng)景典型如——我們是業(yè)務(wù)的下游,上游系統(tǒng)產(chǎn)生數(shù)據(jù)后,需要將數(shù)據(jù)同步到下游系統(tǒng)讓流程繼續(xù)進(jìn)行,并且流程的及時(shí)性要求高,不能有延遲。這種情況下,只有上游系統(tǒng)知道什么節(jié)點(diǎn)產(chǎn)生了數(shù)據(jù),因此只有等他產(chǎn)生數(shù)據(jù)后主動(dòng)推送給下游系統(tǒng),因?yàn)橄掠蜗到y(tǒng)因無法知道數(shù)據(jù)生成的時(shí)間,也就無法及時(shí)去獲取數(shù)據(jù),這時(shí)最好的方式是讓對(duì)方主動(dòng)將數(shù)據(jù)同步過來。

2. 搞清楚數(shù)據(jù)交互的實(shí)時(shí)性要求

a. 對(duì)于我方是數(shù)據(jù)使用方的情況,要根據(jù)業(yè)務(wù)的需要決定獲取數(shù)據(jù)的實(shí)時(shí)性。

如上文所說,如果是用戶使用功能時(shí)需要的數(shù)據(jù)就是即時(shí)性訪問。如果是定期獲取基礎(chǔ)數(shù)據(jù),根據(jù)我們對(duì)數(shù)據(jù)準(zhǔn)確性的要求和對(duì)方數(shù)據(jù)變更的頻率決定獲取的周期。如我們對(duì)數(shù)據(jù)的準(zhǔn)確性要求不是100%的要求,且對(duì)方的數(shù)據(jù)變更頻率也不是很高,則周期可設(shè)計(jì)得長(zhǎng)一些,如每天一次,每幾個(gè)小時(shí)一次等。

b. 對(duì)于我方是數(shù)據(jù)提供方的情況,則以對(duì)方的業(yè)務(wù)需要為準(zhǔn),但是對(duì)于獲取數(shù)據(jù)的訪問量大等特殊情況,應(yīng)在需求中或評(píng)審中做好說明和交代,以幫助開發(fā)設(shè)計(jì)更滿足需要的接口。

3. 選擇合適的接口方式

結(jié)合接口的不同類型和實(shí)時(shí)性要求兩方面,可以選擇合適的接口實(shí)現(xiàn)方式:

a. mq消息隊(duì)列

是一個(gè)中間件,數(shù)據(jù)提供方將數(shù)據(jù)放到中間件,數(shù)據(jù)獲取方從中間件中獲取數(shù)據(jù)。針對(duì)向多個(gè)系統(tǒng)同步基礎(chǔ)數(shù)據(jù)的需要,消息隊(duì)列是最適合的方式。

若選擇這種同步方式,要注意的一點(diǎn)是:增量同步還是全量同步,若是增量同步,對(duì)方是增量獲取還是全量獲?。咳羰侨客?,在什么情況下,對(duì)方應(yīng)該更新數(shù)據(jù),什么情況下應(yīng)該更新數(shù)據(jù)?

b. otter同步

數(shù)據(jù)同步方直接訪問數(shù)據(jù)獲取方的數(shù)據(jù)表將數(shù)據(jù)寫入對(duì)應(yīng)的表中,這種方式實(shí)時(shí)性最高,若對(duì)數(shù)據(jù)的準(zhǔn)確性要求很高,此方式是很好的數(shù)據(jù)同步方式。

c. http

一般在功能設(shè)計(jì)中常用的接口是此種方式,雙方通過http地址保持?jǐn)?shù)據(jù)同步和通信。

在設(shè)計(jì)具體的數(shù)據(jù)同步接口時(shí),具體的方式產(chǎn)品經(jīng)理不用關(guān)注,由開發(fā)根據(jù)需求設(shè)計(jì)合理的方式,然后產(chǎn)品可幫助開發(fā)一起確定所選方式是否滿足業(yè)務(wù)需要。除非業(yè)務(wù)上有特殊要求,則在需求中可指定具體的方式。

三、如何編寫接口文檔

不同的接口使用場(chǎng)景,需要關(guān)注的點(diǎn)和交代清楚的規(guī)則不一樣,以主動(dòng)/被動(dòng)+數(shù)據(jù)使用方/數(shù)據(jù)獲取方的維度,有以下四種情況:

1. 如果是向?qū)Ψ较到y(tǒng)主動(dòng)推送數(shù)據(jù),則可按以下方式整理接口需求

2. 如果是對(duì)方主動(dòng)來獲取數(shù)據(jù),則可按以下方式整理接口需求

3. 如果是被動(dòng)接收對(duì)方推送的數(shù)據(jù),則可按以下方式整理接口需求

4. 如果主動(dòng)從對(duì)方獲取數(shù)據(jù),則可按以下方式整理接口需求

PS:在下一篇文章中將以具體的文檔實(shí)例來說明不同的場(chǎng)景應(yīng)該考慮和注意的點(diǎn)。書寫過程中一些偏技術(shù)的點(diǎn)應(yīng)及時(shí)與開發(fā)咨詢和溝通,防止編寫的文檔與實(shí)際出入太大;接口的開發(fā)肯定涉及兩個(gè)系統(tǒng),因此在評(píng)審前與對(duì)方產(chǎn)品對(duì)好文檔是必須的,要保證雙方開發(fā)拿到的文檔標(biāo)準(zhǔn)是一樣的,否則在開發(fā)過程中會(huì)出現(xiàn)雙方約定不一致導(dǎo)致需要修改的情況。

#專欄作家#

果果,人人都是產(chǎn)品經(jīng)理專欄作家。擅長(zhǎng)業(yè)務(wù)導(dǎo)向性的產(chǎn)品設(shè)計(jì),以及對(duì)業(yè)務(wù)流程的梳理和復(fù)雜問題的拆解,希望能找到產(chǎn)品工作的操作指南和方法論,不斷搭建自己的知識(shí)體系

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自Unsplash, 基于CC0協(xié)議

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 能在里面加一下示例就更棒了。謝謝

    來自江蘇 回復(fù)
  2. 返回參數(shù)是不是只是系統(tǒng)記錄一下,不會(huì)在頁面展示吧

    來自上海 回復(fù)
    1. 這個(gè)看實(shí)際的業(yè)務(wù)需要,有一些信息是關(guān)鍵的業(yè)務(wù)信息,肯定是要解析轉(zhuǎn)化后展示在界面上的

      來自廣東 回復(fù)
  3. 明白這是給開發(fā)的需求文檔,另外想問 對(duì)外的專業(yè)接口文檔 也是產(chǎn)品來寫嗎?有沒有什么標(biāo)準(zhǔn)的參考模板?thx

    來自廣東 回復(fù)
    1. 對(duì)外的專業(yè)文檔還是由開發(fā)來寫比較好,因?yàn)槔锩嬉瑢?shí)例的;你可以到阿里或騰訊的開放平臺(tái)看看,上面有很多開放的API接口文檔,對(duì)外專業(yè)的就是那種的

      來自廣東 回復(fù)
  4. JSON實(shí)例怎么寫呢,比如JSON列表這種怎么表達(dá)報(bào)文???

    來自四川 回復(fù)
    1. 這種就讓開發(fā)寫,產(chǎn)品不寫這個(gè) 哈哈哈

      來自廣東 回復(fù)
    2. 我在迭代的時(shí)候會(huì)寫。列個(gè)表格,包括字段、字段屬性和定義,著重說明想去掉哪些字段增加哪些字段和原因就行。
      需求期間就著重寫場(chǎng)景,當(dāng)輸入什么時(shí)返回什么也要列表說清。
      接手以前的老接口與主干接口時(shí),需要明白用了哪些接口標(biāo)準(zhǔn)與協(xié)議,在對(duì)應(yīng)接口使用處標(biāo)明,需要有接口本身介紹,錯(cuò)誤編碼和示例。
      但我問了其他產(chǎn)品朋友,有些都不需要寫接口需求,大概每種產(chǎn)品經(jīng)理都不一樣吧。

      來自四川 回復(fù)
  5. 謝謝麻雀,寫的很好!

    來自四川 回復(fù)
    1. 謝謝肯定~~

      來自廣東 回復(fù)
  6. 您好,想請(qǐng)教下:
    1.這個(gè)表格對(duì)于簡(jiǎn)單的接口會(huì)比較容易寫,但是對(duì)于里面多個(gè)json格式的要怎么寫呢?
    2.一般在寫對(duì)外的接口文檔中,我們經(jīng)常要列【序號(hào)、字段英文名、字段中文名、是否必填、類型】等;您提供的表格是不是用于產(chǎn)品經(jīng)理向開發(fā)提需求的時(shí)候用的,而不是開發(fā)對(duì)外提供的接口文檔?
    3.感覺【字段來源】、【邏輯驗(yàn)證規(guī)則】提供了新思路,謝謝分享~

    來自廣東 回復(fù)
    1. 是的 我這個(gè)只是產(chǎn)品給開發(fā)的接口需求描述文檔,不是向外介紹接口的專業(yè)接口文檔

      json格式的我理解應(yīng)該是有主信息和明細(xì)信息區(qū)分,可以再分一列來交代是主信息,包含哪些明細(xì)

      專業(yè)開放接口的文檔還是要參考一些開放平臺(tái)上的說明,除了文檔外要加上實(shí)例,你可以參考騰訊云、阿里云這些開放平臺(tái)上的接口看看

      來自廣東 回復(fù)
    2. 好的,謝謝~

      來自廣東 回復(fù)
  7. 您好,請(qǐng)問向?qū)Ψ较到y(tǒng)推送數(shù)據(jù)時(shí),是對(duì)方系統(tǒng)調(diào)用我方接口嗎?;被動(dòng)接收對(duì)方推送的數(shù)據(jù)時(shí),是我方調(diào)用對(duì)方接口嗎?

    來自北京 回復(fù)
    1. 向?qū)Ψ较到y(tǒng)推送數(shù)據(jù)時(shí):是咱們?cè)L問對(duì)方的接口,將數(shù)據(jù)推給他
      被動(dòng)接收對(duì)方推送的數(shù)據(jù)時(shí):是對(duì)方訪問咱們的接口把數(shù)據(jù)推過來
      你剛好理解反了 ??

      來自廣東 回復(fù)
    2. 現(xiàn)在明白了,誰主動(dòng)誰就去調(diào)誰的接口 ??

      來自北京 回復(fù)
    3. 誰被動(dòng)誰給接口

      來自四川 回復(fù)
    4. 是的

      來自北京 回復(fù)
  8. 增量同步還是全量同步,若是增量同步,對(duì)方是增量獲取還是全量獲?。咳羰侨客?,在什么情況下,對(duì)方應(yīng)該更新數(shù)據(jù),什么情況下應(yīng)該更新數(shù)據(jù)?
    ————————————–
    增量同步和全量同步是不是貼重復(fù)了,可以再解釋一下嗎,不太懂這兩個(gè)的區(qū)別,以及產(chǎn)品經(jīng)理要明確什么,想學(xué)習(xí)一下,謝啦

    回復(fù)
    1. 增量的意思就是:持續(xù)同步新產(chǎn)生的數(shù)據(jù),即每次只同步截止上次同步產(chǎn)生的新數(shù)據(jù)
      全量的意思就是:每次都把所有的數(shù)據(jù)都同步過去,不管是否已經(jīng)同步過了

      來自廣東 回復(fù)
    2. 增量接收的意思就是:對(duì)方每次接收到數(shù)據(jù)后按新數(shù)據(jù)對(duì)待,將接收的數(shù)據(jù)插入到數(shù)據(jù)庫中
      全量接收的意思就是:對(duì)方每次接收到數(shù)據(jù)后全量更新之前的數(shù)據(jù)(以一定的唯一維度更新),若已有數(shù)據(jù)中沒有的時(shí)候才插入新數(shù)據(jù)

      來自廣東 回復(fù)
    3. 這一塊產(chǎn)品只需要作為一個(gè)考量因素,具體方案可以在出方案的時(shí)候跟技術(shù)一起商討確定;主要還是看業(yè)務(wù)上的情況 以及數(shù)據(jù)的量等因素共同確定

      來自廣東 回復(fù)
  9. 老實(shí)說。最后一張表沒看懂。

    來自上海 回復(fù)
    1. 就是你通過傳參數(shù)的方式從對(duì)方接口獲取你想要的數(shù)據(jù);比如傳輸你的姓名,對(duì)方給你返回你的姓名、身份證號(hào)、手機(jī)號(hào)等等

      來自廣東 回復(fù)
    2. 標(biāo)題行管的到返回參數(shù)列碼?比如“傳輸給對(duì)方的請(qǐng)求參數(shù)”、“狀態(tài)”等,也屬于“字段名稱”嗎?還有表2其實(shí)也有這個(gè)問題。

      來自上海 回復(fù)
    3. 也算呀 請(qǐng)求參數(shù)就是一個(gè)個(gè)字段的 自然就有字段名稱嘛 狀態(tài)本身就是個(gè)字段

      來自廣東 回復(fù)
    4. 沒想到你竟然回復(fù)了。

      來自上海 回復(fù)
  10. 感謝分享

    來自北京 回復(fù)
  11. ??

    回復(fù)
  12. 下周和合作方對(duì)接!我好激動(dòng)!接口文檔產(chǎn)品要寫嗎?需求里應(yīng)該咋寫

    回復(fù)
    1. 寫需求文檔就行了 按上面的模板寫應(yīng)該可以 但也要看你們的具體要求

      來自廣東 回復(fù)
  13. 學(xué)習(xí)了??!期待下一篇的文檔實(shí)例!

    回復(fù)
  14. m

    回復(fù)
  15. 學(xué)習(xí)了!接口需求沒具體寫過

    回復(fù)
  16. 贊,期待下一篇 ??

    來自北京 回復(fù)
  17. 寫得好呀。接口文檔可能存在的坑太多了。字段的數(shù)據(jù)源/冪等處理/不同場(chǎng)景下主鍵的選擇。還有最重要的,在面多多個(gè)合作方時(shí),如何說服對(duì)方使用自己的標(biāo)準(zhǔn)API。

    來自上海 回復(fù)
  18. 寫的很好,接口需求在需求文檔里我從來沒寫過,領(lǐng)教了,希望多寫一些這樣的文章

    來自上海 回復(fù)
  19. 高手啊

    來自河北 回復(fù)
    1. 1

      來自廣東 回復(fù)
    2. 謝謝~

      來自廣東 回復(fù)
  20. 接口文檔一般不是開發(fā)寫嗎?

    回復(fù)
    1. 這是需求文檔哦

      回復(fù)
  21. 您好 請(qǐng)問文章可以轉(zhuǎn)載嗎???

    來自廣東 回復(fù)
    1. 要轉(zhuǎn)載到哪里呢?

      回復(fù)
  22. 感覺這應(yīng)該是IT方案需要知道的基本知識(shí),產(chǎn)品只需要知道業(yè)務(wù)場(chǎng)景需要哪些數(shù)據(jù),然后具體實(shí)現(xiàn)由SE制定方案

    來自廣東 回復(fù)
    1. 是的 產(chǎn)品就是要交代清楚哪些節(jié)點(diǎn)要跟哪個(gè)系統(tǒng)進(jìn)行什么樣的交互 具體交互方式由研發(fā)定

      回復(fù)
  23. MQ中丟了,同步增量還是全量

    回復(fù)
    1. 嗯嗯 是的 增量同步還是全量同步 以及增量消費(fèi)還是全量消費(fèi) 都要定義好 不然容易出bug

      回復(fù)
  24. 下一篇什么時(shí)候出呢

    來自江蘇 回復(fù)
    1. 還不一定哈 工作太忙就比較少時(shí)間寫 有問題可以先交流??

      回復(fù)
    2. 謝謝~

      來自廣東 回復(fù)
    3. 多謝關(guān)注哦,還不一定啥時(shí)候?qū)懲??

      來自廣東 回復(fù)
  25. 產(chǎn)品經(jīng)理如果熟悉架構(gòu)師的工作,的確增加不少競(jìng)爭(zhēng)力。

    回復(fù)
    1. ??還有很多東西要學(xué)習(xí) 現(xiàn)在還只是淺層的認(rèn)識(shí)

      回復(fù)