Ищите API для изображений автомобилей, и два совершенно разных продукта откликнутся. Один вид принимает фотографии, которые у вас есть: он сохраняет загрузки дилеров, удаляет фон, обрезает, сжимает и отображает их. Другой вид генерирует изображение из данных автомобиля: фотографии не существуют, пока не поступит запрос. Команды регулярно оценивают один продукт, в то время как им нужен другой, поэтому этому различию стоит посвятить отдельную страницу.
Что на самом деле решают пайплайны загрузки
API загрузки — это инфраструктура для фотографий. Он отвечает на вопросы, такие как где хранятся фотографии продавцов, как они очищаются и изменяются по размеру, и как они попадают на CDN. Если ваш продукт зависит от документирования конкретных физических автомобилей, их вмятин и одометров, этот конвейер неизбежен, и его качество проявляется в скорости обработки и обработке крайних случаев.
Что решают API доставки
API доставки, такой как наш, отвечает на другой вопрос: как выглядит эта спецификация? Он отображает точную комплектацию в точном цвете по данным производителя, идентично оформленную для каждого автомобиля, доступную до того, как будет сфотографирован или даже построен любой физический автомобиль. Он не может показать царапину и никогда не покажет неправильные колеса.
| Пайплайн загрузки | API доставки | |
|---|---|---|
| Источник | Ваши фотографии | Данные производителя |
| Показывает состояние | Да | Нет, по дизайну |
| Согласованность | Как хороши фотографии | Идентичные по конструкции |
| Покрытие | Что было сфотографировано | Весь каталог |
| Доступно | После съемки | До того, как машина существует |
Архитектура, на которую попадают большинство платформ
Зрелый ответ — многослойный. Доставляющий API предоставляет справочный слой: последовательные главные изображения, полные наборы углов, правильные комплектации для каждого автомобиля с первого мгновения. Конвейер загрузки несёт доказательный слой: фотографии состояния, документы о повреждениях, конкретный автомобиль. Объявления, файлы претензий и лоты аукционов выглядят лучше, когда два слоя явно различаются, потому что каждый из них отвечает на тот вопрос, на который он действительно хорош.
- Справочный слой из данных: мгновенный, равномерный, полный
- Слой доказательств из фотографий: конкретный, честный, условный
- Четкое визуальное разделение, чтобы одно не выдавало себя за другое
Вопросы интеграции, которые стоит задать заранее
Для конвейеров загрузки: что происходит с пятимегабайтным снимком с телефона при масштабировании, и кто платит за хранение на десятилетие. Для API доставки: правильно ли разрешается обрезка, и покрывает ли лицензия ваши поверхности. Для обоих: как они соединяются в вашей модели данных, что обычно означает одну запись автомобиля, содержащую как каталогную ссылку, так и список медиа. Сделайте правильную форму записи, и два продукта никогда не будут конфликтовать.
Если вы попали сюда в поисках ответов по интеграции загрузки, но ваша реальная проблема — это непостоянное изображение списка, начните с страницы для маркетплейсов вместо этого. Это более распространённая путаница, и её дешевле исправить.
Миграция между двумя
Продукты часто начинают с загрузки и добавляют слой доставки позже, и соединение безболезненно, если запись автомобиля была спроектирована с учётом обоих. Добавьте справочник каталога рядом со списком медиа, заполните пропуски, разрешив сохранённые VIN, и переключайте поверхности по одной. Сетка объявлений обычно конвертируется первой, потому что именно там хаос загрузки наиболее заметен.
Имена тоже имеют значение. Внутри вашей команды называйте два слоя ссылкой и доказательством, а не рендерами и фотографиями, потому что второе название вызывает неправильный спор. Никто не спорит о том, должно ли доказательство заменить ссылку — все спорят о том, должны ли рендеры заменить фотографии.
