京东详情主接口后台实测只有 78%描述、图文、销量这些字段还经常拿不全。这篇把 item_get_desc98%和 item_review99%两个侧链路接口的请求和报文逐字段拆开给一条能落地的补字段链路。一、先看清成功率分布再决定谁当主力做京东数据链路第一步是把后台实测的成功率数据摆出来直接决定每个接口的角色接口实测成功率角色定位item_get78%主详情允许失败但别押宝item_get_pro78%富详情与主接口同水位item_get_desc98%描述与图文侧链路主力item_review99%评价数据销量信号替代item_history_price75%历史价格低频使用item_search28%避开主链路只做人工触发补采这个分布里有两条结论。第一京东主链路天然有约五分之一的调用落空落空之后怎么补字段比怎么重试更重要——盲目对 78% 的接口做三次重试期望成功率也只有 98.9%代价却是三倍调用而且碰上缓存了脏结果的情况重试也救不回来。第二描述类字段有 98% 的专用接口根本不该从主接口硬拿——侧链路不是备胎是该当主力的地方。调用习惯上再给两个小建议类目、详情这类读多写少的数据cache保持默认的yes实测能明显压低execution_time只有调试参数写没写对的时候才临时切no确认完记得切回去不然每次都是源站实时取。还有一个容易忽略的口径京东item_get那 22% 的落空并不都长一个样。有的是直接吐 4 开头的错误码有的是error_code为0000但item里缺关键字段——前者不计费、可以放心重试后者已经计费了重试纯属重复花钱。所以编排逻辑要按错误码和字段完整度两个维度分别兜底这也是下面几节的主线。二、item_get_desc请求与报文拆解网关不变https://api-gw.onebound.cn/jd/item_get_desc/。公共参数还是key / secret / api_name / cache / result_type / lang那一套业务参数只有num_iid京东商品 ID纯数字或带J_前缀均可。这里有个和 1688 不一样的细节京东的num_iid是 10 位左右的纯数字不像 1688 报价 ID 那么长但入参清洗的规则不变——去掉J_前缀再传同一款商品就不会因为入口不同被存成两条记录curlhttps://api-gw.onebound.cn/jd/item_get_desc/?key你的keysecret你的secretnum_iid100012043978cacheyesresult_typejsonlangcn返回报文的item部分核心字段{error_code:0000,item:{num_iid:100012043978,description:pimg src\//img13.360buyimg.com/n1/jfs/t1/aaa.jpg\//pp面料90%棉.../p,desc_imgs:[http://img13.360buyimg.com/n1/jfs/t1/aaa.jpg]}}字段口径逐个说字段含义实测注意点description详情 HTML 源码协议相对 URL//开头落库前要补https:desc_imgs已提取的纯图数组做图文展示直接用它别自己再解析 HTMLnum_iid回传的商品 ID校验一下与请求一致防止缓存串号三个实操坑都在description上一是图片协议相对地址前端直接img src会因协议问题挂掉二是京东详情 HTML 里混有运营端遗留的样式脚本垃圾清洗时要按白名单过滤标签而不是黑名单三是详情图文里经常藏着规格表面料成分、尺码这是主接口拿不到、选品又最需要的字段。规格表在报文里通常长成tabletrtd面料/tdtd90%棉/td/tr.../table抽取时按行拆tr、按列拆td两列的当键值对存三列以上的整行存进 JSON——别试图把所有规格表解析成统一结构京东商家做表的手法五花八门解析得越聪明碎得越厉害。动手前建议先拿真实报文对照一遍再写解析调试入口在 开放平台控制台需要的自取。三、HTML 清洗把描述变成可存储的干净字段importrefrombs4importBeautifulSoup ALLOWED{p,img,table,tr,td,br,strong}defclean_desc(html:str):白名单过滤 协议修复 纯文本抽取ifnothtml:return,[]soupBeautifulSoup(html,html.parser)fortaginsoup.find_all():iftag.namenotinALLOWED:tag.unwrap()forimginsoup.find_all(img):srcimg.get(src,)ifsrc.startswith(//):img[src]https:src imgs[i[src]foriinsoup.find_all(img)]textre.sub(r\s, ,soup.get_text( ,stripTrue))returntext,imgs清洗结果建议存两份desc_text纯文本做搜索和成分抽取用和desc_imgs图数组做前端展示用原始 HTML 再留一份在raw_json里。归一化一定会漏东西能回捞原始报文比重新调接口便宜得多——毕竟0000是计费的。四、item_review 99%销量信号的替代口径京东item_get的销量字段缺失是常态而评价接口实测99%是最稳的替代信号源defjd_reviews(num_iid,key,secret,page1):rcall(jd,item_review,num_iidnum_iid,pagepage,keykey,secretsecret)ifr.get(error_code)!0000:returnNonereturn{total:r.get(comments_count),# 评价总数good_rate:r.get(good_rate),# 好评率tags:r.get(tags,[]),# 高频评价标签latest:[c[content]forcinr.get(comments,[])[:10]],}口径要摆正评价总数只能做相对排序不能当绝对销量。两个商品比哪个更热用它没问题换算成实际出货量就不行。另外tags如质量好“物流快”是做差评分析和选品文案的好素材主接口完全没有这个信息comments里翻车的具体描述攒够样本后反过来就是 1688 选品时的避坑清单。五、降级编排谁失败谁补位deffetch_jd_item(num_iid,key,secret):maincall(jd,item_get,num_iidnum_iid,keykey,secretsecret)itemmain[item]ifmain.get(error_code)0000else{}ifnotitem.get(desc_text):desccall(jd,item_get_desc,num_iidnum_iid,keykey,secretsecret)ifdesc.get(error_code)0000:text,imgsclean_desc(desc[item][description])item[desc_text],item[desc_imgs]text,imgs item[reviews]jd_reviews(num_iid,key,secret)# 异步更好returnitemorNone关于重试成本多说一句失败如果落在4000 / 4001 / 4002 / 4017这几个请求侧错误码上按官方口径不计费可以放心重试但拿到0000却缺字段的调用已经计费了这种情况下重试主接口不如直接切侧链路——78% 的主接口重试期望收益跑不过 98% 的侧接口。六、收尾这套主接口 侧链路补位的编排跑下来京东链路的字段完整度能从主接口单打独斗的水平提上来而平均调用成本反而更低。最后一条建议给每个字段记一个source_api后续哪个接口水位变化比如主接口哪天跌到 70%能立刻知道该从哪里补。
