平臺方對接方案

數(shù)據(jù)對接

對接內(nèi)容

1. 品牌車系車型基礎(chǔ)信息，如名稱和互相的關(guān)聯(lián)關(guān)系
2. 車型的配置信息
3. 關(guān)聯(lián)的圖庫信息（圖片鏈接，關(guān)聯(lián)的車型車系）

對接方案

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

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

文章內(nèi)容

文章本身所包含的信息

1. 文章標(biāo)題
2. 文章內(nèi)容（html結(jié)構(gòu)，我方可以parse成任一格式，比如裝換成一個區(qū)分文本和圖片的json_list結(jié)構(gòu)）
3. 作者信息，指在bee上編寫這個文章的用戶
4. 組織團(tuán)隊(duì)信息，文件夾路徑
5. 若是機(jī)器生成的底稿，會帶上當(dāng)前文章描述的品牌車系車型信息（id）

發(fā)布時需要選擇的信息

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

• 注：所以在調(diào)用發(fā)布接口時，我們可以提供上述的所有信息

發(fā)布對接

對接內(nèi)容

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