Добрый день!
Подскажите, пожалуйста правильный запрос по API для того, чтоб добавить корректно товар.
Точнее сам запрос имеется тонкость нужна в отправке запроса характеристик товара. Я могу добавить только существующий вариант характеристики а создать новую одним запросом не могу. Возможно кто-то сталкивался с этим, и решил этот вопрос. Очень прошу поделиться правильным запросом.
Одним запросом не сможете. Вначале нужно выгрузить все характеристики, а потом при выгрузке товаров указать id характеристики и значение для товара.
1 лайк
Это же практически лишает смысла существование api - слишком много запросов и надо где-то во внешней системе еще и дублировать, хранить id базы сайта… А выходит слишком много кода надо воротить, хранить дополнительно данные, много запросов потребуется выполнить для столь простой операции, а по итогу еще и вероятность отказа будет высокой.
по мне так все логично и правильно. Вначале нужно подготовить данные для наполнения карточки товара, а потом уже наполнять карточку необходимыми данными. Как будете идентифицировать характеристики с значениями в товаре без записи id характеристики во внешнюю систему или id характеристики из внешней системы в CS-Cart? Идентификаторы то разные и нужно использовать один - либо из CS-Cart либо из внешней системы.
Хорошо иметь такую возможность, но это часто невозможно и не нужно. И хорошо бы иметь возможность использовать в качестве идентификатора само значение. Передать значение - если соответствует одному из имеющихся - использовать существующее, если нет - создать новое и использовать его. При импорте товаров из CSV/XML мы же не передаем id значений, вот ровно с тем же смыслом. Чтобы была возможность не наворачивая ненужной дополнительной логики и кучи запросов просто передать из внешней системы карточку товаров.
Это вопрос стоимости владения системой и времени/средств необходимых для проведения необходимых интеграций. У Карта она очень высока и её стоит снижать - многие крайне простые задачи превращаются в слишком сложные. И это как раз один из примеров таких задач. Вы предлагаете вместо мелкой доработки наворотить какую-то сложную и дорогую прослойку. Которая к моменту своей реализации может быть уже и не нужна.
PS… а еще документация может быть прямо с примерами - это делается для наглядности и опять же снижения стоимости владения системой, снижения порога входа.
Вот пример, специально к кому относится замазал.
Идентификатор - значение? например:
характеристика “Вкус” то это и должен быть идентификатор? Если так то как выгрузить несколько языков? Получается для каждого языка будет своя характеристика. В CS-Cart есть объект - характеристика и для него может быть несколько языковых переменных. Поэтому название характеристики не может быть идентификатором.
Хорошо, раз вы считаете это логичным и правильным подходом, то объясните мне в чем здесь удобство? В моем случае нужно прикрутить api для создания товара (одежда). С размерами да, я создам их и буду использовать их id. А вот как насчет цветов??? Здесь же как напридумывают серо-буро-пошкрябаный, цвета утренней сопли и т.п. Как в этом случае??? Без данной возможности придется постоянно лезть и создавать нужный вариант через админку или api. А так создал сразу вариант характеристики и не паришься 3-мя запросами, чтоб присвоить вариант характеристики. И да поддержу предыдущего оратора, касательно того, что в документации не даете полный пример запроса, чтоб видеть данные, которые можно передать. Сейчас вообще никак не удобно…
Может. Большинство магазинов на CS-Cart по факту имеют всего один язык. И всегда есть основной язык, по умолчанию. Сами подумайте или посмотрите примеры решения этой задачи в других системах. Это выдуманная проблема, да и набор простых решений очевиден, один из них опять же применен в CS-Cart для товаров импорта из файлов. Есть куча других вариантов решения, без создания сложностей при создании простого товара и кучи запросов туда-сюда. API ж нужно не для того чтобы в разработке попрактиковаться и понапридумывать кучу каких-то сущностей, которые еще потом отдельно надо актуализировать и поддерживать(эти самые id, которые внезапно в одной из систем могут поменяться). А для решения вполне конкретных, зачастую довольно небольших задач. А тут вместо скрипта в 30 строк для передачи карточки товаров из одной системы в другую надо мудрить практически параллельную CMS + синхронизировать дополнительно еще сервисные данные и т.д. т.к. иначе рано или поздно появятся критические ошибки из-за расхождения этих самых id… ну бред же.
Прошу прощения что вмешался, но мне кажется вы немного путаете механизмы.
API - это доступ к объектам в базе данных. Этот механизм. по-сути, позволяет выполнить функцию update_product, не более. В таком случае для работы действительно нужна дублирующая база, которая позволит хранить айдишники CS-Cart и при необходимости синхронизировать справочники. Примеров таких реализаций очень много, так как они защищают от возможных опечаток пользователей или дублирований названий у разных по-сути объектов.
Если вы хотите просто передавать данные в импровизированном формате с предобработкой на стороне CS-Cart, так зачем вам API? Создайте пресет для импорта товаров, задайте любые удобные для вас шаблоны. Далее достаточно просто обновлять файл и запускать импорт. Такой механизм будет работать и с названиями характеристик, и с несуществующими вариантами.
А мне кажется, что тут как раз перепутана суть. Ведь API нужен не для доступа к объектам в базе данных. Эти объекты сами по себе вообще не нужны. API нужен для непосредственно решения интеграционных задач. Что-то передать, из одной системы в другую, что-то взять. Т.е. для обмена непосредственно нужными данными. Не создания бесконечных механизмов синхронизации айдишников, которые до бесконечности усложняют разработку т.к. имеют свойство меняться(то что сегодня в одной системе id характеристики “цвет” - 123, а значение “красный” имеет id 2 не значит, что завтра это будет точно так же). Проблема в том что в некоторых случаях при разработке API забыли зачем он вообще нужен и начали писать действительно интерфейс для доступа к каким-то объектам. Но если при этом не помнить, зачем собственно эти объекты нужны получается какая-то странная и довольно бесполезная конструкция, когда для решения простой практической задачи надо вместо одного запроса сделать 5, да к тому же еще где-то хранить id из другой базы данных и т.д. И создавать себе целую кучу мест отказа. А ведь нужно то было РЕШИТЬ бизнес-задачу, а не создать себе проблему в виде системы которую невозможно обслуживать.
Ведь API делается для интеграции разных систем, которые надо заставить работать вместе. Там может и не быть возможности вообще что-то стороннее хранить в силу различных обстоятельств, да и не нужно это часто. А тут выходит какое-то нецелесообразное переусложнение.
1 лайк
Могу показать простой кейс. Вы в своей системе ведете товары и передаете на сайт. У вас есть товар со значением цвета “серо зеленый”. Вы передали, на сайте создался такой вариант. На следующий день на сайте менеджер решил подправить название варианта и цвет стал “серо-зеленый”. Не зная об этом, вы сохраняете передаете из своей системы опять же тот же товар и на сайте вариант меняется, а вы получаете уже 2 разных варианта. Еще один кейс, с характеристиками, которые могут иметь одинаковые названия.
При всех подобных ситауциях вы получаете множество проблем вместо того, чтобы просто вести за своими локальными вариантами “id сайта”. В случае создания нового варианта, просто один раз выполнить запрос по созданию варианта на сайте. При этом, вышеописанные кейсы проходят абсолютно без проблем. Варианты могут иметь любые названия. Вы полностью защищены от опечаток пользователей, переименования объектов и прочих подобных проблем.
Именно поэтому все API служб доставок, оплат и кредитов всегда используют исключительно API построенное на идентификаторах (как числовых, так и буквенных).
Согласен, вы можете использовать на сайте один язык, запретить редактирование вариантов и характеристик на сайте, работать с одним API-клиентом и т.д. Но кому-то нужна и полная реализация. Зачем обрезать многофункциональный механизм в угоду частного случая? Используйте импорт, почему он вам не подходит?
1 лайк
Так нет такой проблемы - если есть ошибка правится параллельно, причем одними и теми же людьми. Кроме контент-менеджеров вообще никто не может трогать карточки товаров. Впрочем, у манагеров и доступа к сайту нет. Тут просто бизнес-процесс должен быть корректный и определена ведущая система.
С ID вообще нет мороки, потому как в действительности вообще всё-равно какой id у характеристики, если значение одно. Ну не меняются они случайно на сайте, не появляются.
“Используйте импорт, почему он вам не подходит?” Потому как он не инициируется из внешней системы и надо еще файлы сохранять. передавать, запускать импорт… и по результату нет обратной связи, ответа - всё ли ок, или нет.
Например выгружаю размеры рубашки. Но в процессе работы магазина покупатели жалуются на то что размер указан неправильно и она меньше указанного размера. Менеджерами принято изменить “Размер” на “Размер (маломерный)” (или как-то там еще). Изменяют в основной системе учета и выгружают по АПИ на сайт. По Вашему сценарию должна создаться новая характеристика с новыми значениями. Но по старой характеристике был настроен фильтр и задействована функционалом других модулей. Например те же самые настройки вывода в темах от АВ. Это чтобы сделать минимальное изменение на стороне учетной системы нужно задействовать целый штат сотрудников для проверки корректности работы интернет-магазина после изменения названия характеристики!!!
Что касается языков то зайдите на сайт в ЕС - французский и английский, немецкий и английский, итальянский и английский и т.д. Учитывая что английский это международный язык общения то необходимо как минимум 2 версии сайта - на национальном языке и на английском. За исключением России и подобных стран где все должно быть только на национальном языке потому что английский знают относительно единицы и продажи возможны только за рубли и в пределах страны и на покупателей-иностранцев можно не расчитывать.
Нет, надо просто немного дальше подумать. Но не с точки зрения вставшего в позу разработчика, а с точки зрения пользователя. Во-первых, значение старой характеристики менять всё-равно нельзя, т.к. к нему могут быть привязаны рубашки не-маломерки. Если нового значения а базе еще нет - создать новое. Если есть - взять уже существующее. С фильтрами ситуация надуманная - если в магазине возможны два варианта характеристики, то они и в фильтрах будут.
С языками проблем нет и оно так же решается, почти как сейчас. Опять же - не уникальная же задача. Не надо создавая один вариант удалять другой.
1 лайк
А если несколько товарных групп? Зачем в одной характеристике значения размеров рубашек и гаечных ключей?
А в чем проблема? Эту проблему CS-Cart уже сейчас как-то решил, при загрузке характеристик по CommerceML. Ничего нового, то же самое. И ведь нормально, работает, все пользуются. Там правда ExternalID есть, но он по сути для красоты и не выполняет ровно никакой роли. Если из 1С выгрузку изменить и в качестве External_ID подставить значения, работать будет точно так же, просто в БД будут дублироваться значения с External_ID. В нынешнем виде это избыточные данные(и хорошо что они есть - могут и пригодиться). Правда… опять же при желании прикрутить связь сайта с 1С по API они, несмотря на своё существование, будут бесполезны. Забавно, обратная ситуация.