平台方对接方案

数据对接

对接内容

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. 我们查看文档后，进行数据对接，并测试然后上线。