Станимир междудругото не е далече от истината как се прави the right WAY с API , но го е обяснил така че никой да не схване за какво иде реч и с някакъв супер измислен пример.
Другото което е че чрез Rest APi ще избегнеш примерно вкарване на дадена категория, да вземем един прост пример от моят опит.
Клиента има сайт със 10 категории тип eMag, иска обаче да направи мрежа от сайтове и всеки сайт да вземе една категория от този главен магазин, благодарение на Rest APi всичко работи коректно.
Кво каза? Какво значение има дали ще пращаш разни JSON-и по апито , или ще пращаш заявки към базата, и какво общо имат категориите? Ако си си описал нещата, как така ще вкараш категория където не и е мястото? WTF
Идеята му е явно да имат всички магазини рест архитектура, която да се чекват взаимно, което едно че е ,тъпо, другото, което е че се пише няколко пъти на няколко места едно и също.
Правилния начин е Service Pattern, или микросървиз, както искаш -> работата му е да проверява от children магазините към сървъра. После сетваш магазините да депендват на тоя сървиз. Как ще го синхронизираш е твоя работа, пък и зависи от ситуацията, може да искаш да става с CRON, а може да искаш да е при определени actions, а може пък да искаш магазините да не пазят при тях изобщо продукти, а всичко да се пази при sync сървъра. Ама трябва и да се попише код и да се бърника, примерно ако 3те магазина са на различна платформа... трябва да им учиш нещата, че да ги навържеш. Ако е нещо къстом, правиш си един сървиз, някакъв общ interface дето шерват всички магазини , това е важно, щото после като почнеш да добавяш други магазини, да знаеш кое как ще се случва и какви са ти методите.
Аз бих го направил с един сървър, при който пазя данни за продуктите, наличностите и т.н.. Тогава бих си написал нещата така, че ще добавям продукти само в този сървър, а той ще споделя разни endpoints към 'children' магазините. Лесно и scalable, и ако искам да имам 100 магазина, няма да се налага да пипам нищо по сървъра, ако съм си написал правилно нещата и интерфейса. Нали са няколко към 15-тина метода в най-лошия случай, дето се споделят.
Реално магазина няма да знае откъде идват данните така или иначе, ще има Repository, а магазина НЕ трябва да знае откъде и как идват данните, в момент в който искаш да разкачиш магазина, само пипаш по репозиторито, дето събира данните, дали от 'мастер' сървъра или от друго място, все тая.
Тъпия начин е да навържеш магазините директно към една база, ама какво става ако някой магазин няма разни пропъртита, или пък има различни такива, които ги няма в другите. Стават едни нагласяния, и не е скалируемо. Един интерфейс ти оправя нещата. А сървъра, който реално държи базата е must, за да имаш унифициран начин да махаш продукти за всички магазини, да редактираш и т.н.. Отделно, ако си впишеш нещата като хората, сървъра изобщо няма да депендва на магазините, и магазините няма изобщо да ги интересува откъде идват данните, точно както трябва да бъдат нещата. За пример , ако единия магазин проверява за продукт дали е наличен, не трябва да го интересува откъде идват данните, дали от сървър 1, или 2, дали от магазин 1, 2 и т.н... , бих си и направил така нещата, че всичко да идва от Repository, което е вързано за сървиза, така в един момент искам да разкача магазина от 'дебелия' сървър, и го разкачам без да пипам нищо по класовете и файловете от магазина, само ще си пипна Репозиторито и ще променя откъде фечвам инфо.
