VkolV, общий интерфейс с функциями типа "проверка карточек, выделение обновившихся", "получение цен", "получение остатков", "выставление цен", "выставление остатков". Дата-классы для передачи данных. Наследники интерфейса, соответственно, реализуют передачу нужных запросов с конвертацией данных в те поля, которые у каждого API свои.
Тут фокус в том, что у двух разных магазинов будут разные потребности в работе с API. Кто мониторит каждый заказ через FBS, кто гонит поставки через FBO, кто комбинирует и ловит исчерпание остатков на FBO, чтобы выставить остатки по FBS и актуализировать цену. Кто один раз настрогал карточек - кто меняет их каждый месяц... и т.д.
API меняется постоянно, у WB уже пятое поколение финансовых отчетов, но работает все через ту же жопу.
Ozon который месяц размахивает своими "квантами", но в API они приткнуты с крайнего боку, хрен найдешь, и консистентности можно даже не искать. Об отзывах-вопросах их просили еще год назад, дальнейшее - молчанье.
Мониторишь нововведения (есть оповещения в ТГ), смотришь, касается ли твоих задач (обычно - нет), делаешь изменения, если понадобилось. Локально.
А один раз сделать и почивать все равно не выйдет.
Вчера с утра у WB взял и тупо отвалился метод, выдающий этикетки для сборки по FBS, например. Хорошо, хоть оперативно (через час) подняли...
0. Определиться, чего тебе вообще надо от API маркетплейсов.
Сюрприз - 80% этого API, скорее всего - не надо.
Сюрприз № 2 - 20% того, что надо, в API до сих пор нет.
А дальше - от поставленной задачи. Мне, например, для интеграции нескольких таких API в общую систему пришлось делать прослойку-адаптер, чтобы единообразно с ними работать. Никакой Swagger под твои задачи абстрагировать не будет.
Вручную - необязательно. Есть Meld, например, позволяющий наглядно сравнить пару папок, в том числе исключительно по дате и размеру, не читая самих файлов.
Третья версия - это не дописанная, а переписанная вторая. Нечего себя запутывать, учите актуальное.
Если понадобится поддерживать более старую версию - разберетесь в разнице после.
Весь список, кроме "Грокаем" - это книги, отвечающие на вопрос "что в моем коде не так, я вроде языки выучил и программирование освоил, куда двигаться дальше". Без созревания этого вопроса их можно даже не открывать.
nik2021, а чего от вас должны хотеть незнакомые люди, от которых вы хотите работы в свою пользу?
Собственно, с заказчиком, который ТЗ даже сам себе толком не представляет - редкий фрилансер и связываться-то станет. Связавшийся, естественно, захочет четко обговорить, ЧТО он делает, сколько за ЭТО получит - и если ЭТО в процессе такой организации работы получилось не совсем ТО, о чем вам мечталось - так это не его вина.
Оптимальное решение тут, имхо - просто забыть парадигму "таскаю с собой всю систему только ради синхронизации данных". И начать решать проблему сначала.
Проблему стоит разделить на две части:
1. Выбор зданий по карте, чтобы с ними работать. Решается подключением виджета от Яндекс.Карт, например.
2. Работа с данными по конкретному выбранному адресу. Тут у вас требуется что-то свое, а что именно - извольте составить ТЗ.
Mmrut, вот я и говорю: есть шанс и научиться пользоваться компьютером, и не испортиться дурными виндовскими привычками. Обстоятельства воистину благоприятны.
Потому что надо не "через флешку", а "с флешки". И уж никак - не из Линукса, а именно загрузившись с загрузочной флешки с виндой (возможно, предварительно придется разобраться с UEFI и SecureBoot).
Ну, или использовать уникальный шанс остаться на нормальной системе и не маяться мастдайкой вовсе.
izuru_hitachi, тогда все-таки стоит не гоняться за готовыми командами, а посмотреть, какие данные реально в этих полях в этих таблицах и не изменит ли их изменение формата поля (скорее всего - нет, но теоретически могут всплыть неприятные сюрпризы). Впрочем, в ответе Akina уже предложил такую проверку.
AlexVWill, только штат адвокатов нанять, если сам владелец в той стране, где на него могут выйти по итогам использования этих VPN "желающими". Впрочем, в этой стране это не поможет.
koder_1, в Битрикс все добавлялось через функции Битрикса, конечно, а не напрямую в таблицы. Правда, был однажды сюрприз с внезапно после обновления переставшим работать методом COrder::SetPaid... после чего перестал надеяться на официальную техподдержку.
Ну, и я уверен, что мои пару компактных таблиц с фьючерсами (которые на момент заказа еще тупо отсутствуют в каталоге) поддерживать намного проще и удобнее, чем тот колхоз, который ради этого пришлось бы наворотить в кастомных полях заказа по-битриксовски. И для последующей работы с этими данными все равно штатные интерфейсы Битрикса не годятся, необходимости завязываться на него - никакой.
Кирилл, вы одинаково реагируете на - скорее всего - спамера, который только что зарегистрировался и задал этот вопрос только для того, чтобы с другой регистрации на него "ответить".
Тут фокус в том, что у двух разных магазинов будут разные потребности в работе с API. Кто мониторит каждый заказ через FBS, кто гонит поставки через FBO, кто комбинирует и ловит исчерпание остатков на FBO, чтобы выставить остатки по FBS и актуализировать цену. Кто один раз настрогал карточек - кто меняет их каждый месяц... и т.д.
API меняется постоянно, у WB уже пятое поколение финансовых отчетов, но работает все через ту же жопу.
Ozon который месяц размахивает своими "квантами", но в API они приткнуты с крайнего боку, хрен найдешь, и консистентности можно даже не искать. Об отзывах-вопросах их просили еще год назад, дальнейшее - молчанье.
Мониторишь нововведения (есть оповещения в ТГ), смотришь, касается ли твоих задач (обычно - нет), делаешь изменения, если понадобилось. Локально.
А один раз сделать и почивать все равно не выйдет.
Вчера с утра у WB взял и тупо отвалился метод, выдающий этикетки для сборки по FBS, например. Хорошо, хоть оперативно (через час) подняли...