WordPress-integráció REST API-val: adatok két rendszer között

Adattulajdonos

Két rendszer eltérő módosításai felülírhatják egymást. Nevezd meg mezőnként, melyik rendszer a hiteles adatforrás.

Az adatok gazdáját mezőnként is érdemes kijelölni. A termék neve például a vállalati rendszerből érkezhet, a marketinges leírást viszont a WordPressben szerkeszthetik. Ha az integráció minden szinkronnál a teljes rekordot felülírja, a helyi munka elveszhet. A felosztás ezért mondja meg, mely mező melyik rendszerben módosítható, és hogyan kezelitek az eltérést. A kétirányú kapcsolat összetettebb, mert ütközést is fel kell oldania. Az időbélyeg önmagában nem minden helyzetben elég a helyes döntéshez. A külső azonosító, módosítási forrás és jóváhagyási állapot is szerepet kaphat. Az adatgazda meghatározása megelőzi azt a hibát, amikor két jóhiszemű szerkesztői folyamat felváltva rontja el egymás eredményét. Egyértelmű, hol kell javítani az eltérést.

Azonosítás és jogosultság

A nyilvános olvasás és a tartalom módosítása eltérő hozzáférést igényel. Használj a feladathoz szükséges hitelesítést és korlátozott jogosultságot.

A hitelesítés és jogosultság két kapcsolódó, de eltérő kérdés: ki küldi a kérést, és mit tehet. A nyilvános olvasási végpont nem jelent automatikusan írási jogosultságot. A módosító kapcsolatnak a támogatott hitelesítési módot és szűk hozzáférést kell használnia, megfelelő titokkezeléssel. Az API-fiók ne kapjon fölösleges rendszergazdai jogot csak azért, mert így könnyebb elindítani a fejlesztést. A kulcs cseréjét és visszavonását is meg kell tervezni. A hibás vagy lejárt azonosításnál az integráció adjon kezelhető jelzést, ne csendben hagyja el a rekordot. A hozzáférési adat ne jelenjen meg URL-ben, nyilvános kódban vagy részletes hibalogban. A kapcsolat biztonsága az üzemeltetés teljes időszakában fennálló feladat. Az integráció csak a szükséges műveleteket végezheti el.

Adatleképezés

A külső mezőnevek és tartalomtípusok nem feltétlenül egyeznek a WordPressével. Dokumentáld a kötelező mezőket, formátumokat és az üres értékek jelentését.

A mezőleképezésben a típus és jelentés egyaránt számít. Az üres szöveg például jelenthet törlést, hiányzó adatot vagy változatlanul hagyást; ezt előre tisztázni kell. Dátum esetén formátum és időzóna, pénzösszegnél pontosság és pénznem, kategóriánál stabil azonosító lehet szükséges. A szabad szöveget és HTML-t külön kezeld, a bemenet ellenőrzését pedig ne hagyd a véletlenre. A hibás rekordhoz érthető mezőszintű visszajelzés segít. A kötelező mező hiánya ne hozzon létre félkész, később nehezen felismerhető tartalmat. A leképezési dokumentum tartalmazzon egy normál mintát és néhány szélső esetet. Ebből a külső rendszer fejlesztője és a WordPress-oldal készítője ugyanazt az adatcserét tudja megvalósítani. Hibás bemenetnél érthető, javítható visszajelzés keletkezik.

Ismételhető művelet

Hálózati megszakadásnál nem mindig ismert, végrehajtódott-e az eredeti kérés. Alkalmazz stabil külső azonosítót és biztonságosan ismételhető feldolgozást.

A hálózat megszakadhat a szerveroldali feldolgozás után, de a válasz megérkezése előtt. A küldő ilyenkor nem tudja biztosan, végrehajtódott-e a kérés, ezért ismételhet. A stabil külső azonosító alapján a fogadó felismerheti a már kezelt rekordot és frissítheti azt új létrehozás helyett. Az egyszerű tartalomszinkronnál is fontos a duplikáció kezelése, fizetést vagy küldést indító feladatnál pedig még nagyobb a jelentősége. A feldolgozási állapotot követhetően kell tárolni, és az ismétlés eredményét is meg kell határozni. Nem minden HTTP-művelet jelent automatikusan üzletileg biztonságos ismétlést. A konkrét végpont szerződése írja le, mi történik azonos kérés újraküldésekor, részleges siker és hiba esetén. Újraküldéskor nem keletkezik duplikált üzleti rekord.

Korlát és napló

Nagy adatmennyiség vagy túl gyakori kérés terhelést okozhat. Használj lapozást, ésszerű ütemezést és adatvédelmi szempontból megfelelő naplózást.

Nagyobb adatmennyiségnél a lapozás és feldolgozási ütem megakadályozhatja, hogy egyetlen kérés túl sok munkát kérjen az oldaltól. A rendszerhatárokat a tényleges tárhely és külső szolgáltató alapján kell kialakítani. A hibás rekord ne feltétlenül állítsa meg az egész csomagot, de a részleges eredmény legyen egyértelmű. A naplóban célszerű korrelációs azonosítóval összekapcsolni a küldő és fogadó eseményét. A diagnosztikához nem mindig szükséges teljes személyes adatot tárolni. A sikertelen tétel újrafeldolgozásának legyen kijelölt útja, hogy ne kézi adatbázis-módosítás legyen az alaphelyzet. A működtető lássa, mikor futott a kapcsolat, hány rekord maradt feldolgozatlanul, és milyen beavatkozás szükséges a folytatáshoz. A hibás rekord és a feldolgozás állapota visszakereshető.

Próba és verziózás

Egy változó külső adatszerkezet váratlan hibákat hozhat. Tesztelj hiányzó mezőt, megszakítást, ismétlést és megváltozott sémahelyzetet.

A tesztben ne csak a sikeres kérést küldd el. Legyen benne hiányzó kötelező mező, érvénytelen azonosító, ismételt rekord, jogosultsághiány és váratlan külső válasz. A szerkezet változása külön kockázat: egy mező átnevezése vagy típusváltása mindkét oldalt érintheti. A verziózás és bevezetési rend segíthet, hogy ne egyik pillanatról a másikra szakadjon meg a kapcsolat. A próbát elkülönített adatokkal és szolgáltatói tesztmóddal végezd, ahol szükséges. Az élesítés után a tényleges forgalom első mintáit is ellenőrizd. A dokumentált végpont és példa akkor értékes, ha megegyezik a kiadott működéssel. Az integráció fenntartása ezért folyamatos együttműködés a két rendszer felelősei között. A kapcsolat módosítása ellenőrizhető és visszafordítható.

Szemléltető helyzet és gyakorlati munkalap

Szemléltető példa: egy vállalat jóváhagyott szakmai anyagokat küld belső rendszeréből a WordPressbe. Az integráció külső azonosítót tárol, így egy ismételt kérés ugyanazt a piszkozatot frissíti, és nem hoz létre újabb másolatot. A publikálás továbbra is szerkesztői ellenőrzést igényel.

Gyakori kérdések