Nem minden ügyfél tud most migrálni. Van, akinek a cash-flow nem engedi a 8–12 hetes átállást. Van, akinek a folyamatai annyira egyediek, hogy egy modern általános rendszer eleinte rosszabbul illene. Az ilyen tenanteknek dolgoztuk ki az API-only mintázatot: a legacy PHP/Drupal ERP marad az egyetlen igazságforrás, de elé egy vékony, modern REST-réteget teszünk.
Mire jó és mire nem
Jó:
- Modern frontendet (Storefront, mobil app, partner-portál) köthetünk az ERP-re anélkül, hogy hozzá kellene nyúlnunk a Drupal core-hoz.
- Az ERP adatait külső rendszerekbe (NAV, banki integrációk, BI) sokkal egyszerűbb kiengedni.
- A modern stack chat-asszisztense (Nortinia Engine) tud kérdezni a legacy ERP-től.
Nem jó:
- Új business logikát NEM ide rakunk. Az új logika a modern stackben születik. A REST-réteg tükör, nem üzleti szabályok helye.
- Tömeges írási műveletek (batch import 10k+ rekord) továbbra is a legacy admin UI-n keresztül mennek.
A hat endpoint-csoport
Minden API-only telepítésünk ezt a hatot kapja meg alapból:
- Customers —
GET /api/v1/customers,GET /:id,POST(csak engedélyezett tenantnak),PATCHszintén. - Products — termék törzs olvasás + készlet lekérdezés.
- Orders — vevő rendelések, állapot lekérdezés és állapot-átmenet (status transition).
- Invoices — kibocsátott számlák, PDF generálás.
- Stock — készlet pillanatfelvétel, raktáranként.
- Reports — előre definiált jelentések futtatása paraméterekkel.
Írási műveletek alapból ki vannak kapcsolva. Per-tenant engedéllyel kapcsolhatók be, és minden mutáció auditálva van.
A három üzemeltetési pillér
API-kulcs auth. Minden hívás X-Api-Key: <key> header-rel, tenantra kötve. Roláció 90 naponta.
Rate limit. Default 60 req/min/tenant. Burst-engedéllyel akár 300, de kérésre. A legacy DB nem bír többet, és ezt a réteget azért tettük be, hogy ne lőjük szét a Drupalt egy elszabadult mobil-app retry-loop-pal.
Idempotency key. Minden POST/PATCH hívás Idempotency-Key headert vár. 24 órán át tároljuk a választ. Ez a rendszer a hálózati flake-ek elleni egyetlen védelem, ami nem dupláz adatot a legacy DB-ben — a Drupal nem tud róla, és nem is fog.
A rejtett csapda: CP1250
A legacy DB szöveges mezői CP1250 kódolásban tárolódnak. A 2008-as Drupal 6 install óta. A modern REST API UTF-8-at vár. A megoldás: minden olvasásnál on-the-fly transkódolás (iconv PHP-ben), íráskor visszafordítás. Ennek két érdekes következménye van:
- Az ékezetes karakterek között van pár, amelyik CP1250-ben ugyan létezik, de a Magyar Helyesírási Szabályzat szerint mégsem szabványos (pl. a régi Drupal néhol
őhelyett\u0151-et tárol). Egy kis sanitizer minden read-on lefut. - A keresés (LIKE %xy%) nem fog ékezet-érzéketlenül működni a legacy DB-n; a REST réteg vagy in-memory szűr (kis listáknál), vagy elutasít (nagy listáknál) — emiatt a frontend nem tud teljes szöveges keresést kínálni, csak prefix-set.
Miért nem forkoljuk a legacy adatot
Végig egy igazságforrást tartunk: a legacy DB. A REST-réteg nem cache-el adatot perzisztensen, csak rövid in-memory TTL-lel (60 mp termékre, 15 mp készletre). Ha duplikálnánk az adatot, két helyen kellene szinkronban tartani — és az pont az ellenkezője annak, amiért az API-only-t bevezetjük.
Hová vezet ez később
Az API-only nem zsákutca. A modern UI komponensek a REST-rétegen át már működnek a legacy ERP-vel; amikor a tenant készen áll a migrációra, a frontend ugyanaz marad, csak a háttér vált. A REST szerződés stabil — a migráció így UI-szinten láthatatlan.