Egy importáló elküld egy új cikket, majd időtúllépést kap. A kezelő újraindítja a teljes folyamatot, és később két bejegyzés jelenik meg. A probléma abból adódhat, hogy az első kérés mentése már megtörtént, csak a válasz nem jutott vissza a klienshez.
Az időtúllépés ezért bizonytalan kimenetet jelent. A következő lépést a szerveroldali állapot visszaolvasása és az API dokumentált ismétlési szerződése alapján kell kiválasztani. A puszta „próbáld újra” kezelés írási műveleteknél nem mindig biztonságos.
Változatlan azonosítóval tedd ellenőrizhetővé a mentést
Saját mintafolyamatunkban az új cikk azonosítója minta-szamitas-ellenorzese, a létrehozáskor elvárt korábbi revízió pedig 0. Ez azt jelenti, hogy az adott azonosító alatt még nem létezhet korábbi bejegyzés. A szerver ellenőrzi ezt a feltételt, és sikeres mentéskor létrehozza az első revíziót.
Ha a kliens nem kap választ, először ugyanezt az azonosítót olvassa vissza. Ha az első revízió létezik, és tartalma megegyezik a feltöltött adatokkal, a létrehozás sikeresnek tekinthető. Nincs szükség egy második, számozott vagy véletlen azonosítójú cikkre.
Ha a visszaolvasás sem sikerül, az eredmény továbbra is ismeretlen. Ilyenkor a folyamat álljon meg egyértelmű állapotjelzéssel. A bizonytalanságot ne nevezze automatikusan sikertelen mentésnek.
Meglévő cikknél a revíziót is egyeztesd
Egy másik példában egy cikket az 5. revízióból szeretnél módosítani. Közben egy szerkesztő már elmentette a 6. revíziót. Ha a kliens csak az azonosítót használja, felülírhatja a szerkesztő újabb munkáját.
A feltételes mentés az elvárt 5. revíziót is elküldi. A szerver a tényleges 6. revízió miatt konfliktust jelez, és változatlanul hagyja a tartalmat. A kliens ezután megmutathatja az eltérést, de nem növelheti vakon az elvárt számot újabb írás kedvéért.
A JSON-összehasonlító használható a kiinduló, a szerkesztett és az aktuálisan visszaolvasott mezők vizsgálatára. A döntéshez a tartalom kell, a státuszkód önmagában kevés.
A HTTP-módszer nem helyettesíti az alkalmazási szerződést
A HTTP szemantikáját leíró szabvány megkülönbözteti a biztonságos és az idempotens módszereket. Az idempotencia az ismétlés kívánt szerveroldali hatásáról szól; nem jelenti azt, hogy minden válasz vagy naplóbejegyzés azonos lesz.
Egy POST-létrehozás ismételhetőségét az alkalmazásnak külön biztosítania kell, például dokumentált idempotenciakulccsal vagy egyediség- és revíziófeltétellel. Ilyen támogatást nem szabad feltételezni pusztán azért, mert a végpont neve ismerős.
A HTTP-fejléc-elemző a bemásolt válasz értelmezésében segíthet. Hitelesítési kulcsot azonban ne másolj bele nyilvános jelentésbe vagy képernyőképbe. A naplóban csak a szükséges, nem titkos hibakód és műveletazonosító maradjon.
Az import haladását bejegyzésenként őrizd meg
Ötven cikkből például húsz visszaellenőrzötten mentett, egynek bizonytalan a kimenete, huszonkilenc pedig még el sem indult. Ez három külön állapot. Az egész csomagot „sikertelennek” nevezni elveszíti a fontos részleteket.
Folytatáskor először a bizonytalan cikket egyeztesd. A már igazolt húsz bejegyzést ne hozd létre újra. A hátralévő műveletekhez ugyanazok az előkészített azonosítók és változatlan tartalmi ellenőrzőösszegek tartozzanak. A közzététel külön lépés is lehet a vázlatok sikeres ellenőrzése után.
Gyakori kérdések
A 401 válasz bizonyítja, hogy a feltöltés működik?
Csak a hitelesítés nélküli vagy elutasított kérés állapotát jelzi. Sikeres mentést a hitelesített írás és az utána végzett visszaolvasás igazol.
Időtúllépés után töröljem a félkésznek gondolt cikket?
Előbb olvasd vissza. Lehet, hogy a mentés teljesen sikerült; bizonyíték nélkül a törlés adatvesztést okozhat.
Konfliktusnál automatikusan a saját változatom legyen az újabb?
Ne írj felül közben módosított tartalmat vakon. Az eltéréseket és a tényleges revíziót össze kell egyeztetni.