平臺方對接方案

數據對接

對接內容

1. 品牌車系車型基礎信息，如名稱和互相的關聯關系
2. 車型的配置信息
3. 關聯的圖庫信息（圖片鏈接，關聯的車型車系）

對接方案

1. 客戶A的數據主要存儲在mysql中。他們單獨分配了一個從庫，通過mysql數據同步的方案，將他們業務庫的數據經過篩選過，同步到這個子庫內。
2. 然后客戶A，將子庫的連接配置給到我方，這個子庫在理論上只是給我方使用，且我方不會進行修改的操作，所以可以只給我們只讀的權限
3. 我們通過每天一次的離線清洗，將數據轉換格式后存入我們的數據庫內（存在時延）。
4. 客戶A在某些場景下，期望我們能比較實時的拉取一些更新后的數據，我們提供了一個接口，可以推送指定的車型id來達到快速更新的流程

1. 客戶B的數據庫不便于直接給到我們，且配置信息愿意直接使用我們的數據格式，所以我們只對接了圖片相關的信息。溝通后，我們通過爬蟲的方式，直接到客戶B的門戶官網抓取了所需要的圖片。

文章內容

文章本身所包含的信息

1. 文章標題
2. 文章內容（html結構，我方可以parse成任一格式，比如裝換成一個區分文本和圖片的json_list結構）
3. 作者信息，指在bee上編寫這個文章的用戶
4. 組織團隊信息，文件夾路徑
5. 若是機器生成的底稿，會帶上當前文章描述的品牌車系車型信息（id）

發布時需要選擇的信息

1. 選擇發布的渠道（頭條，百家等）
2. 選擇每個渠道發布的賬戶
3. 渠道的參數選擇（如是否原創，話題選擇，推送草稿/直接發送）
4. 其他發布配置（如定時發布的時間）

• 注：所以在調用發布接口時，我們可以提供上述的所有信息

發布對接

對接內容

1. 客戶A提供他們發布接口的API文檔，描述參數信息。若有一些平臺特有的邏輯，則需要詳細描述（如要選擇平臺的話題，則要描述如何）。
2. 客戶A提供一個測試賬戶讓我們測試，期望是能登陸到客戶后臺進行編輯的，這樣我們可以在測試后刪除測試內容。
3. 我們查看文檔后，進行數據對接，并測試然后上線。