寻找车辆图像数据库的团队通常有明确的需求：我们希望图像在这里，在我们的基础设施中，没有人能把它们拿走或减慢速度。这种直觉是正确的。从中得出的结论，购买一堆文件，通常并不正确，因为图像数据库不是一次性购买的产品。它是一个需要永久维护的负债。
拥有数据库的真正含义是什么
- 导入：海量文件、命名规范，以及与您现有的车辆数据的映射
- 更新：新车型、改款车型和新品牌不断推出，因此静态数据库在购买后的一个季度内就会过时
- 覆盖缺失：垃圾桶里没有的，你也不会有，没有任何请求能填补它
- 许可：每个文件都需要您在法律询问时能够提供的来源，即使是在购买多年后
- 提供服务：存储、CDN、调整大小和格式转换现在是您的管道
这些单独来看都不难。但它们共同构成了一个永久的、不引人注目的内部产品，只有一个客户，而一旦维护者换了团队，命名规范就成了考古学。
API模型取代了什么
API 反转了所有权：目录、其更新、其配置映射和其许可证均由提供商保管，而您的系统保存标识符。像 brand/model/year/trim/view 这样的请求加上参数返回当前正确的图像，包括在您购买转储时尚不存在的车型年份。稳定的 ID 确保您今天存储的引用在目录演变时仍能解析；查看 完整品牌和车型覆盖范围 以了解其背后的内容。
大多数生产系统最终选择的混合型
保证访问的本能仍然需要回答，而答案是缓存，而不是购买。通过 API 解析，然后将返回的图像存储在您自己的存储桶和 CDN 中，并以您的车辆记录为键：
- 必须在五年内重新生成的文件（政策、合同、档案）保留本地副本
- 热路径从您的CDN提供服务，永不等待任何人
- 在目录更新时刷新，所以修正和新年无需重新购买
像所有者一样缓存，像订阅者一样解析。您获得了使数据库具有吸引力的控制权，而无需继承其维护
从转储到查找
已经拥有图像数据库的团队很少需要一次性大规模迁移。有效的模式是“勒索式”：新的表面从第一天开始通过 API 解析，现有的表面继续读取旧文件，旧的存储不再接收更新。在一个目录周期内，过时的图像变得比解析的图像更差，这时剩下的表面会因为产品需要而转移，而不是因为迁移计划。
首先要检查的真正障碍是合同上的。有些旧图像库的许可条款禁止在同一表面上混合来源，解决这个问题需要法律对话，而不是工程对话。在编写第一个适配器之前解决它，因为它决定了过渡期是否可以同时显示两个来源。
該模式的成本機制，以及為什麼緩存請求會改變賬單，請參見 每月車輛圖像 API 成本是多少；集成細節請參見 車輛圖像 API 頁面。
