车辆图像上传与图像交付

搜索车辆图像API，两种完全不同的产品会出现。一种接受你拥有的照片：它存储经销商上传的照片，去除背景，裁剪，压缩并提供它们。另一种则从车辆数据生成图像：直到请求到达之前，照片都不存在。团队经常评估一种，但实际需要的是另一种，因此这种区别值得单独一页来介绍。

上传管道实际解决的问题

上传API是照片的基础设施。它回答了诸如卖家照片存放在哪里、如何清理和调整大小，以及它们如何到达CDN的问题。如果您的产品依赖于记录特定实体车辆的凹痕和里程表，那么这个流水线是不可避免的，其质量体现在处理速度和边缘情况处理上。

像我们的交付API回答不同的问题：这项规格看起来是什么样子？它根据制造商数据渲染精确的车型和颜色，每辆车的框架完全一致，在任何实体车辆被拍摄或甚至建造之前就可用。它无法显示划痕，也不会显示错误的轮胎。

成熟的答案是分层的。交付API提供参考层：一致的主图，完整的角度集，正确的配置，每辆车从第一秒开始。上传管道承载证据层：状态照片，损坏文档，单个车辆。列表、索赔文件和拍卖批次在两层可见区分时看起来更好，因为每一层都回答了它最擅长的问题。

对于上传管道：五兆字节的手机照片在大规模情况下会发生什么，谁来支付十年的存储费用。对于交付 API：修剪是否正确解析，许可证是否涵盖您的表面。对于两者：它们如何在您的数据模型中结合，这通常意味着一个车辆记录同时持有目录引用和媒体列表。将该记录形状搞对，两个产品就不会冲突。

如果您是为了寻找上传集成的答案而来，但您的实际问题是列表图像不一致，请先查看市场页面。这是更常见的混淆，也是更便宜的解决方案。

产品通常先从上传开始，然后再添加交付层，如果车辆记录是为两者同时设计的，那么接口就很顺畅。在媒体列表旁边添加目录参考，通过解析存储的VIN进行补全，然后逐一切换表面。列表网格通常首先转换，因为那里的上传混乱最明显。

命名也很重要。在团队内部，将两个层次称为引用和证据，而不是渲染和照片，因为后一种表述会引发错误的讨论。没有人会争论证据是否应该取代引用；每个人都会争论渲染是否应该取代照片。