tft每日頭條

 > 職場

 > 産品經理口中的接口

産品經理口中的接口

職場 更新时间:2025-01-19 18:32:44

剛接觸産品工作時,對接口(API)一片空白,不理解接口(API)是什麼?更别說能看懂接口文檔了,在接口上踩了很多坑。接下來,将結合自己的親身經驗與大家分享。

産品經理口中的接口(産品經理如何繞開API的坑)1

比如這些場景:

場景1:開需求會,提了新的需求,開發說,你這個需求太複雜,光接口就有20幾個,根本做不完。我一聽就蒙了,雖然表示懷疑,卻無力反駁。

場景2:好不容易理好接口,提了新的需求,,開發說,你把讀寫接口搞混了,不可能一個接口實現所有功能。

場景3:其他部門向我提了兩個接口需求,我找到開發完成接口後交付給需求方,結果需求方說接口的響應時間和并發數達不到要求,得推倒重做,oh my god!

究竟接口是什麼呢?又如何看懂接口文檔?接口性能對功能的影響是什麼呢?如何在産品需求中理清接口呢?這篇文章将解答你的疑惑。

一、API是什麼?

API是應用程序編程接口,如何理解呢?

API就好像是一個傳輸數據的通道,入口需要請求數據,就好像是通關密碼,而出口需要返回結果。

接口的使用方不需要關心接口是如何實現的,他隻關心能不能拿到接口最後的返回結果。

接口的提供方需要定義接口請求參數、響應内容等,還需要關注接口的性能,是否能滿足高并發的調用,接口的穩定性如何……

二、如何看懂接口文檔

以一個真實的接口文檔做範例,給大家講解:

産品經理口中的接口(産品經理如何繞開API的坑)2

接口一般分為以下幾個部分:

1、接口描述

簡單描述接口的邏輯和作用

2、接口地址

接口的正式url和接口測試的url,需求方通過調用接口url,獲取響應内容

3、請求方法

一般來說,接口最常見的請求方法為GET和POST兩種方式,即讀接口和寫接口。通過這兩種方式,實現對數據的增删查改。删查改本質都是寫的動作。

4、請求參數

即需要請求的字段名的名稱和規則:

産品經理口中的接口(産品經理如何繞開API的坑)3

都是哪些字段,字段的類型是什麼,是否必填字段等等

5、響應内容

接口返回的字段名稱和規則

注意:大部分開發往往不會把所有的字段羅列,隻會列出比較重要的字段。

當你發現,接口文檔中沒有你需求的字段,别着急找開發,可以看下實例中,有沒有需求的字段。

比如這個文檔,你可以很明顯的發現,響應内容中缺少了數據寫入狀态這個字段,但是在後續實例中,是包含has sucess這個字段的。

産品經理口中的接口(産品經理如何繞開API的坑)4

6、錯誤代碼

對接口的錯誤用代碼進行歸類,以便能快速找到錯誤原因,解決問題。

7、實例

實際調用時的響應的内容。

三、接口性能

不同的業務場景對于接口性能的要求是各不相同的,所以在做接口之前,一定要開發讨論,正在做的接口是否能滿足調用的需求,未來是否會增加新的調用方,擴展性如何?不然就會出現,前文中場景3的悲劇。

接口如何優化,pm可以不用了解,由開發去把關,但我們需要知道接口性能的核心指标。

1、接口響應時間、并發數

接口響應時間:

從請求端發送一個請求開始,到接收到響應結果所經曆的時間。

并發數:

指同時訪問服務器站點的連接數。

可以進行簡單估算,如果響應時間<200ms,1s=1000ms,1000/200=5,如果有10個線程,秒并發>50,一分鐘就可以連接超過50*60=3000次,一個小時就可以連接超過3000*60=180000次

如果有20個線程,那秒并發可以超過100。

實際的并發數并不總是符合我們的期望,需要壓測或者實際使用才能知道接口能支持的最大并發數是多少。

響應時間越短,多線程并發數越高,接口性能越好。

不是所有的業務場景都需要“最好”的性能,滿足業務場景即可。

2、線程

一個程序有多個進程,一個進程有多個線程。

如果把上課的過程比作進程,那麼每個學生就是一個線程,CPU是老師,教室是内存,他們共享教室,即線程共享進程的内存空間。每一個時刻,隻能一個學生問老師(CPU)問題,老師回答完畢,接着回答下一個學生問題。

三、如何在産品需求中理清接口

1、如何拆解接口

大家牢記一句話,接口分讀接口和寫接口。

不管多複雜的需求,涉及到多少個接口,其本質就是讀接口和寫接口。

舉幾個例子:

  1. 遊戲點券充值接口
  2. 獲取用戶列表接口
  3. 評論标記精選接口
  4. 投放卡券接口

其中,1、3、4都是寫接口,請求方式為POST,因為都涉及到寫入相關數據的動作。2是讀接口,請求方式為GET,涉及讀取和查詢數據。

這樣來看,接口貌似很好理解,有寫入數據的就是寫接口,有讀取數據就是讀接口

但是在理産品需求時,産品小白常常理不清楚功能對應的接口,解決辦法很簡單,就是拆解需求。

比如我們要設計一個身份證實名認證的功能,需要滿足一個身份信息隻能實名認證一個賬号,如果用戶認證了數據庫裡已經存在的身份證,那麼會提醒用戶身份信息被占用。

首先,我們需要拆解需求:

  1. 實名認證是針對未實名的用戶,已實名過的用戶無需再進行實名,所以我們需要一個查詢接口
  2. 還需要一個寫接口,讓用戶去寫入身份信息或修改身份信息
  3. 因為一對一的要求,所以還需要一個查詢數據庫是否存在已有的身份信息
  4. 某些用戶實名後,可能會因為各種理由,想解除實名,所以還需要一個删除的接口

其次我們需要明确接口傳輸的字段

2、接口的請求和響應字段

(1)接口需要請求哪些字段,是否必填,字段的格式有什麼要求嗎?

比如上面提到的(3)查詢數據庫是否存在已有的身份信息,請求字段為會員ID,姓名,身份證号,均為必填字段,姓名首先必須得純中文,身份證号也必須滿足位數要求。

(2)接口需要返回哪些字段,是否必填,字段的格式有什麼要求嗎?

原理同上

3、最後啰嗦一些注意事項

除了功能和邏輯外,還需要注意接口的異常和錯誤情況,

(1)前端做好交互,提示用戶,以免因為接口不穩定,導緻線上bug,而前端缺乏引導,導緻用戶不能正常操作,對産品頗多怨言。

(2)對于某些重要的功能,還要做好兩手準備,準備兩個接口,一個接口挂掉還可以用另外一個接口。

本文由 @丹小喵 原創發布于人人都是産品經理。未經許可,禁止轉載。

,

更多精彩资讯请关注tft每日頭條,我们将持续为您更新最新资讯!

查看全部

相关職場资讯推荐

热门職場资讯推荐

网友关注

Copyright 2023-2025 - www.tftnews.com All Rights Reserved