中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

產品經理要是知道一些技術知識，在溝通和協調時團隊效率會高很多。本文分享的API知識，能幫助大家更好與技術同學溝通，一起來學習下。

今天寫一篇B端產品經理的 API 接口相關知識點，很多招聘崗位JD上都有要求產品經理能夠實現跨系統的對接，尤其是現在做到 ERP 的產品包括國內的電商和國外電商都要求這一塊作為一個能力上面來進行體現。看了網上一些資料，以及自身一些看法對這塊做個概括總結，從 8個方面來展開。

1. 產品經理在這個過程中接口文檔適用對象以及在什么環節里用？
2. 接口的使用場景。
3. 接口文檔形式，到底是長什么樣子？站在產品層面它的理解上面絕對會比前后臺的頁面上面的設計來的都復雜，講究的是業務之間的流轉。
4. 接口對接流程上的梳理，拿到接口怎么去對接？業務要做什么？產品經理要做什么？開發要去做什么？測試要去做什么？運營上線之后還要去做什么？
5. 系統流程梳理，也就是接口文檔對接清單。
6. prd需求文檔里面關于接口的寫作手法，要知道產品會關聯哪些系統？調用哪些接口？詳細寫明輸入輸出，調用接口的一些傳入值。
7. 梳理接口的注意的事項點，在這個過程中就六個方針，不要在這個過程遺忘了。

①注意要測試環境和生產環境生產上線時候要提醒研發換到生產環境調用。

②注意必輸字段和選輸字段，要傳入字段的含義和校驗。枚舉值不清楚含義的要詢問對方含義，比如說單據類型字段枚舉值是 B2C發貨單，采購退貨發貨單等。

③ 注意唯一ID之間的關聯，比如說我們訂單系統的發貨單號是 001，到 wms系統是否生成了一個新單號 A001,那發貨回執時候wms要給 oms系統 001 單號。

④注意基礎信息的映射，比如說倉庫代碼和對方倉庫代碼是否一樣，商品編碼和對方商品編碼是否一樣。如果不一樣還要進行映射，那映射的工作是誰來做，

⑤ 注意行信息和明細(我們常說的 list)數據。哪些在行中，哪些在明細中，看的是單據和字段的關系，是一對一還是一對多，一對一就在行中，一對多就在明細中。比如說發貨單只有一個發貨倉，那么就是在行中，但是一個發貨單有多個商品，那就在明細中。

⑥接口文檔字段的校驗，比如說發貨單下發 wms，wms會校驗商品是否存在，倉庫是否存在等，這些校驗服務于業務需要，比如說商品都不存在，我怎么發貨呢對吧，所以雙方系統的基礎數據要對齊。

⑦同步方式:增量和全量。一般在做基礎數據同步的時候，比如說商品檔案，會員信息等，增是指的是增加的變動的推送給其他系統。

⑧接口文檔常用的一些名詞，面試的時候有的面試官會問到 ERP 接口，那我在這個時候怎么回答？

首先第一個問題接口對于主流做B端產品的像涉及到電商需要對接OWTB等多個系統平臺是需要接口能力的。要比寫需求文檔難度上一個層次，PRD 里面涉及的的業務流，功能數據，所有界面和說明都是在這個環節要完成的但是接口文檔在這里面的話是作為加分項，它會更加復雜一點，既要理解 oms平臺系統是做什么的，你要理解wms系統做什么的，把這種系統流程圖畫出來，才能去理解說在這個過程中要去涉及對接系統的哪些接口。

那我們使用接口的2個場景：一個是前端開發工程師去調用后端的接口，另一個的場景的話是后端去調后端的接口。

首先我們要知道最基本的前提兩個系統之間它是怎么去傳遞數據的，比如我熟悉的ERP，它是一個大系統，那 ERP 下面的話又會分為，采購系統，銷售訂單系統，庫存管理系統，還有對接第三方的賬單支付系統，那這個過程中就是整個單據處理的流程遇到的多個子系統，關系到數據之間是怎么傳遞的？這是后端與后端之間的一個對接。

還有一個是前端對接后端，所有涉及到的 c 端的界面，比如說開權限，所有在這個過程中看到的界面都是來自于后臺在配置。C端的每個頁面，不是寫死的數據就是調用后臺接口，包括日常淘寶購物的時候，這個商品詳情頁本質上就是前端開發工程師在調用后端開發工程師的接口，前端開發和后端開發中后臺系統之間的一些對接。

再比如說簡單的一個app提交訂單的步驟，它其實需要通過訂單系統創建待支付訂單，這個時候有支付接口需要調用第三方的支付系統去完成支付，還有所涉及到的商品系統，庫存系統，銷售系統，以及最后獲取物流觸發的物流系統。它在整個訂單的履單的過程中，點擊提交訂單步驟上就是前端開發工程師調用了訂單的系統，后端開發工程師有一個叫創建待支付訂單的結果，跳轉到支付系統待支付訂單創建成功之后，用戶選擇支付方式，支付系統會調用支付接口完成支付，支付系統知道支付完成后上報給訂單系統，訂單變成已支付待發貨狀態，那與此同時都有在做的事是他們之間會一個個去查這里面所有下單的商品有沒有上下架？下架了這創建訂單也會失敗，這就是我們所涉及到的話，就是后臺，后臺的子系統之間調用來調用去。

大概有個認知之后，再說一下接口文檔的形式和接口文檔要怎么跟這個系統流程圖來進行梳理？要明確一點，前臺只要不是寫死的數據，就是調后端的接口，跨系統之間所涉及的。那這種隊列是怎么實現的？就是 API 接口，就是兩個系統之間數據的傳輸，比如說訂單只要把發貨單下發下去了，人家倉庫wms那邊才能去發貨，發完貨后把結果告知我，那我在這個過程中知道我的始發的數量是多少件，這是通過接口告訴我的。

接口梳理了哈。

舉一個例子：一個是調用支付接口，一個是某開放平臺，大型公司都有自己的開放平臺的，我是賣衣服的某平臺，平臺上完成的交易是不是要通過第三方比如微信支付寶去扣買家微信賬戶或者支付寶里面的錢嘞？那這個時候跨系統對接，我就要去調微信支付寶的接口，去找到這個平臺的文檔對接中心 ，那 API 接口里面有哪些東西呢？第一個就是接口名稱，第二個就是接口上面什么場景下來進行使用？比如說我小程序上面的一個支付，那我進去就要找小程序上面的一支付就好了。 第三個接口請求的地址這一側的話是開發比較關注的，請求參數，簽名，這些東西全部都是開發的。

具體輸入的參數里面應用上面的字段產品側要去進行明確，接口名稱，接口應用場景，請求參數里面看業務字段，請求參數里面我們所涉及到的，必填項的一些輸入值。

一般來說是商務部門先對接接口的。訂單號這塊有個問題，就是訂單系統產生的訂單號，還是支付系統產生的支付單號？因為一個訂單可以多支付的，一個訂單所涉及到的發起了一次支付，但是用戶等了兩分鐘他都沒付，這個單子就會自動關單了，后面他又發起了一個支付，所以你一個訂單是多筆支付單號在傳的時候的話，更精準的應該傳的是支付單號，而不是訂單號。這些單號作為唯一的的條件，這個東西是千萬不能搞錯的。

我作為產品，我必須要去理清楚我們公司到底傳的是什么單號，先不用在意選填項，在這個過程中我們主要的話要去看一下必填項，它在這個過程中會涉及到枚舉值。什么叫枚舉值？枚舉值就是用于表示一組有限選項的數據類型，比如性別。

產品經理要去根據你的業務場景來進行限定，怎么來定義接口側的正常和異常，所涉及到的接口失誤錯了，那倉庫編碼的話我們默認傳的話是一般的數字，你傳給我的這個倉庫編碼，我在我們系統里查不到，結果報錯。這就是我們在輸入項的時候的話，尤其是必傳項，有沒有按照我的規則來進行傳？這接口接收失敗，也會同步告訴你接口接收失敗的原因是什么，那要是成功完了之后的話它會涉及到的輸出參數，這個輸出參數在你其他的一些的所涉及到的字段里面應該也會用到的，這個是需要去關注的，所以我們接口上面大概知曉一下重要項是輸入輸出。

那我們下一個問題在于，輸入輸出我怎么知道它的輸入是什么？它的輸出是什么？我怎么知道是我提供接口，還是我的另一個對接方來進行提供接口？

拿一個開放平臺來講一下業務場景，這個就是有 多個商家會入駐到這個平臺上來進行賣貨。所以的話我們在這個過程需要根據每個商家比如說他的輸入參數會涉及到它的整體的請求參數，都是輸入參數也就是會涉及到供應商編碼也就是商家編碼是什么？平臺會分配給你的編碼是什么？到底要什么狀態？如果說接的訂單是已審核狀態，我要往下進行履單。要搞清楚拉什么時間段單子？接什么訂單的類型？后續要送的哪個收貨倉？因為不同的模式，包括的話收貨地址這個要去看，包括我在這個過程中你訂單有沒有期望的送貨時間，訂單層級需詳細到到底下單了哪一些商品的條碼？需要的數量是多少？這個全部都有接口給到，因為商家就是拿著這一些輸出到他們自己的訂單系統里面，然后去對接下游的 wms 的系統和tms物流系統去發貨，wms系統發完了貨之后它還有一個接口就是發貨結果告訴平臺，可以很清楚的知道運單號是什么？發了多少數量？哪個供應商？對接的哪個渠道的物流？以及快遞單號是什么？那產品側只要去關注接口的名稱，接口的調用是靠什么機制來進行調用，輸入輸出參數。

現在來說下要怎么知道是你給我接口還是我給你接口？ 那首先第一個的話，在一般接口對接的時候，最起碼我要知道我們系統負責做什么事情，別人的系統負責做什么事情。

①與公司業務人員溝通，與系統對接方產品/技術描述業務場景，溝通發放接口文檔材料

②拿到材料之后 API接口過多請對方圈定一下接口，在場景上如果少接口則繼續和對方溝通確認。

③看 API接口，不太清楚哪些系統進行調用可以將材料發放研發團隊一起査看溝通，比如哪些接口是前端商城研發調用，哪些接口是支付系統調用。在輸入值時如果涉及到要查別的系統數據，這個要在流程圖中進行說明。

④看 AP接口，接口的輸入輸出，尤其針對枚舉值，選輸必輸進行進一步確認。對于必輸字段并不懂的輸入的業務含義和對方確認，和自己的業務方確議。

⑤繪制系統流程圖與AP|接口清單，梳理功能點，繪制原型和寫 PRD 文檔?！疽紤]正向和逆向，逆向取消，逆向售后。是否存在修改場景?

⑥PRD 文檔中增加與外對接 API接囗對接的輸入輸出邏輯說明。

⑦開發和測試環節對接過程中存在疑問繼續跟蹤。如果對方還在開發的接口項目管理同學要跟蹤進度。測試進行聯測，對方測試人員要進行配合看數據。當然如果測試可以自己看到別人系統后臺那要去看其他系統后臺的數據。

⑧上線研發要換成生產環境的測試地址，和對方提前溝通上線時間和上線順序，上線時是否要留相關人員。

第二是我怎么知道有這么多的系統上面對接的接口？那還是一樣的你要知道你的系統里面做什么事情，別的系統里面做什么事情，你的系統存了什么數據？別的系統存了什么數據，你才知道我什么時候要找別人的系統來進行合作？那怎么去判斷呢？正常系統是有自己的規范，所涉及到的其他行業也有其他系統上面的規范。一個剛入職的產品需要接手，那首先就是看后臺，比如說訂單管理里面有哪一些的字段，商品管理里面有哪一些的字段，這個系統里面存了什么數據，有所涉及到的接口的，要去梳理接口上對接，注意區分接口提供方和接口調用方。

接口梳理規則:

①前端(app 或者小程序或者 h5 頁面等)調用別人系統的接口

②同步:同步指的是實時得到結果。異步:實時得不到結果，比如訂單系統把發貨單下發wms系統，wms系統只能給到接收成功或者失敗，等到倉庫發完貨才調用 訂單系統接口告知發貨實際的結果。訂單需要多增加一個接口 接口發貨回執。

③一般從數據上下游傳遞數據下游方，上游方調用下游方接口。箭頭指向誰，誰提供接口。數據流轉方向繪制箭頭，一般是推送，但是如果1個上游方對接 N 個下游，上游方會定義接口，改為下游拉取上游接口。

④考慮逆向流程:【要考慮正向和逆向，逆向取消，逆向售后。是否存在修改場景?】

接口文檔常用名詞：

①同步和異步。同步指的是同一時間處理，異步指的是不能實時處理，處理完結果再告知結果，會新增接口對接。

②拉取和推送，一般接口遵從誰是數據上游方，推送給下游，但是如果1個上游方對應N個下游方，這個時候上游機會提供拉取接口，下游都來拉數據。這樣因為減少上游方開發工作量。

③上報聯調，跨系統對接時把接口調通。

④Mock。有時候上下游沒時間和開發聯調，這個時候開發可以造數據自己先調。一般開發用postman工具 mock接口。

⑤調用地址/URL。生產環境測試環境

⑥API接口和 MQ都是跨對接方式，MQ【消息隊列/消息中間件】可以用于內部系統對接非實時部分，具體看研發設計。

最后提一個面試題，很多面試官會問：和第三方系統對接時要做哪些產品工作？

①在業務正向和逆向流程調研完成之后校理系統流程，核理對接的AP1接口清單:我們需要調用三方哪些接口，三方需要調用我們哪些接口。

②在產品設計時和三方溝通接口輸入輸出字段，寫進PRD的接口傳值說明中。

③產品需求評審之后研發提測，測試測試，上線時間等項目計劃同步三方，研發測試上線協調三方配合相關任務。

④上線之后問題和需求跟蹤判別，如果涉及到三方系統的和三方產品進行溝通。