CMS și API

Webhook-uri și procesare în loturi.

Selectați livrarea sincronă, webhook sau lot din volum, latență, reîncercare și proprietate operațională.

Clarificați sarcina și decizia

Acest ghid transformă webhook-urile și procesarea loturilor într-un flux de lucru de operare care poate fi revizuit. Conectează deciziile de domeniu, proprietatea, dovezile și acceptarea, astfel încât rezultatul să continue să funcționeze în producție.

Selectați livrarea sincronă, webhook sau lot din volum, latență, reîncercare și proprietate operațională.

Proces practic

  1. 1

    Tipuri de surse de inventar, identificatori, câmpuri, locații, proprietari și stări de publicare.

  2. 2

    Alegeți modelul de livrare dintre volum, latență, control editorial și toleranță la eșec.

  3. 3

    Mapați înregistrarea sursă într-o înregistrare separată a versiunii de limbă cu o legătură durabilă.

  4. 4

    Adăugați autentificare, idempotence, reîncercare, invalidare cache, logare și controale de acces.

  5. 5

    Testează publicarea, modificările sursei, rezultatele indisponibile, derularea înapoi, operarea tastaturii și monitorizarea înainte de lansare.

Exemplu sau instrument

O diagramă ciclului de viață devine un contract de implementare pentru reîncercări, idempotence, monitorizare și reluare. În instrument, înregistrați, de asemenea, valoarea de bază, proprietarul, decizia, dovezile, problema deschisă și data aprobării. Utilizați o pagină reală sau o tranzacție, astfel încât echipa să vadă dependențele, excepțiile și lucrările de întreținere care urmează după lansare.

Punct de decizieÎnregistraCriteriul de acceptare
Linia de bazăStarea curentă observatăSursa și data înregistrate
DecizieOpțiunea selectată și justificareaRisc și audiență luate în considerare
DoveziTestați, documentați sau măsurațiRevizuabil și specific versiunii
AprobareNume, rol și dataToate criteriile obligatorii îndeplinite

Alegeți livrarea dintre latență, volum și proprietate

Utilizați livrarea sincronă pentru cererile interactive mici care se finalizează în mod normal în timpul expirării interfeței și pot raporta imediat un rezultat. Utilizați webhook-uri când munca este asincronă, dar fiecare rezultat ar trebui să intre în CMS de îndată ce este gata. Folosiți procesarea în loturi pentru colecții programate mari, importuri controlate sau migrări în care debitul și reproductibilitatea contează mai mult decât livrarea imediată. Modelele pot coexista, dar fiecare clasă de conținut ar trebui să aibă o valoare implicită documentată.

Estimați volumul zilnic și de vârf, dimensiunea articolului, timpul acceptabil de finalizare, fereastra de reîncercare, cerința de comandă, capacitatea examinatorului și proprietarul operațional. Un rezultat rapid nu are valoare dacă coada editorială nu îl poate procesa. Includeți limitele în amonte și în aval: exportul CMS, rata API, lucrători în coadă, punctul final de apel invers, scrierile bazei de date, invalidarea memoriei cache și volumul de lucru de revizuire. Selectați cel mai simplu model care îndeplinește obiectivul complet al serviciului.

ModelFolosiți cândControl esențial
SincronCerere mică și latență limitată scurtăTimeout cu reîncercarea sigură a clientului
WebhookLocurile independente ar trebui să sosească promptVerificarea semnăturii și gestionarea evenimentelor idempotente
LotSet mare controlat și finalizare programatăManifest, punct de control, reconciliere și reluare

Implementați un ciclu de viață webhook verificabil

Acceptați numai HTTPS POST, verificați semnătura față de corpul brut, verificați toleranța marcajului de timp și respingeți versiunile de evenimente neacceptate. Stocați ID-ul evenimentului sub o constrângere unică înainte de a aplica modificări de afaceri. Returnați succesul după primirea durabilă, apoi procesați în mod asincron. Un eveniment repetat aduce succes fără a repeta efectul secundar. Rotiți secretele de semnare cu o perioadă de suprapunere și restricționați rezultatul de diagnosticare, astfel încât să nu dezvăluie semnăturile sau conținutul.

Stări model, cum ar fi primit, validat, potrivit, aplicat, ignorat, reîncercare și eșuat. Potriviți rezultatul cu ID-ul jobului, ID-ul sursei, revizuirea sursei, localitatea și modul. Dacă sursa curentă este mai nouă, stocați rezultatul pentru audit, dar nu deschideți și nu înlocuiți versiunea curentă. Gestionați evenimentele în afara ordinului conform regulilor de tranziție ale statului, mai degrabă decât prin ordinea de sosire. Păstrați un instrument de reluare care necesită un motiv, identitatea operatorului și domeniul de aplicare.

  1. 1

    Verificați transportul, semnătura corpului brut, marcajul de timp, tipul evenimentului și versiunea contractului.

  2. 2

    Persistați evenimentul unic și confirmați primirea durabilă.

  3. 3

    Rezolvați sarcina și revizuirea exactă a sursei înainte de a schimba CMS.

  4. 4

    Aplicați o tranziție de stare idempotent și creați schița care poate fi revizuită.

  5. 5

    Înregistrați finalizarea sau direcționați evenimentul către reîncercarea controlată și reluare.

Faceți loturile reproductibile și reconciliabile

Creați un manifest imuabil cu ID-ul lotului, ora creării, regula de interogare sau de selecție, ID-ul articolului individual, revizuirea sursă, localitatea, modul, prioritatea și suma de verificare. Înghețați manifestul înainte de trimitere, astfel încât o interogare CMS ulterioară să nu poată schimba ceea ce înseamnă lotul. Împărțiți-l în bucăți delimitate și utilizați chei stabile de idempotnță pentru fiecare articol. Finalizarea punctului de control după scrieri durabile, astfel încât lucrătorii să poată relua fără să o ia de la capăt.

La sfârșit, reconciliați articolele trimise, acceptate, finalizate, respinse, învechite, nereușite și omise în mod intenționat. Numărările trebuie să fie echilibrate cu manifestul inițial, iar fiecare articol nefinalizat are nevoie de un motiv și următoarea acțiune. Redarea unui subset creează un nou manifest de redare legat de originalul. Nu modificați numărul inițial și nu ștergeți dovezile eșuate. Publicați rezultatele loturilor numai în stările de revizuire, cu limite ale volumului de lucru care protejează echipa editorială.

  • Manifestul fixează identitatea articolului, revizuirea sursei, setările și suma de verificare.

  • Fiecare operație de element este idempotent și poate reîncerca independent.

  • Punctele de control se reiau după întrerupere fără a dubla schițele.

  • Starea finală numără reconciliază exact cu manifestul.

  • Reluarea este acoperită, autorizată, conectată și auditabilă.

Monitorizați cozile și repetați recuperarea

Monitorizați rata acceptată, rata de finalizare, rata de eroare în funcție de categorie, adâncimea cozii, vechimea articolului cel mai vechi, percentilele de durată de procesare, eșecurile verificării webhook, numărul de reîncercări, volumul scrisorilor moarte, rata rezultatelor învechite și timpul de la rezultat până la aprobarea editorială. Alertă cu privire la impactul utilizatorului și la creșterea întârzierii, mai degrabă decât la eșecurile tranzitorii izolate. Tablourile de bord separă procesarea furnizorilor, livrarea apelului invers, aplicația CMS și timpul de așteptare editorial.

Runbook-ul identifică proprietarii, pauză sigură, limitele de scalare, rotația acreditărilor, aprobarea reluării, gestionarea scrisorilor moarte, comunicarea cu furnizorul și verificarea recuperării. Reapelarea pierdută a exercițiului, eveniment repetat, eveniment nerespectat, întrerupere a furnizorului, întrerupere CMS, nepotrivire a schemei, secret expirat și finalizare parțială a lotului. Acceptarea necesită recuperare fără publicare duplicat, pierdere silențioasă, editare manuală a bazei de date sau eliminarea ultimului conținut aprobat.

Roluri, dovezi și aprobare

Mențineți generația separată de publicare. Un răspuns de succes este o schiță, nu o aprobare. Stocați identificatorul și versiunea sursei, setările de transformare, identificatorul de rezultat, starea de revizuire, aprobarea și timpul de publicare. Când sursa se schimbă, marcați versiunea lingvistică pentru revizuire în loc să înlocuiți în tăcere conținutul aprobat. Acest lucru face posibilă rollback-ul și auditul pe toate platformele.

Operațiuni și întreținere

Lucrarea nu se termină la publicare. Conectați versiunea sau configurația lingvistică la sursa acesteia, monitorizați măsurile de calitate și servicii și definiți declanșatorii de revizuire concreti. Declanșatorii includ modificări de sursă, modificări legale, noi nevoi de public, întrebări de asistență recurente, modificări tehnice și incidente. Un proprietar numit evaluează declanșatorul, deschide o nouă revizuire atunci când este necesar și înregistrează aprobarea reînnoită.

Listă de verificare pentru publicare

  • Integrarea folosește identificatori durabili de sursă.

  • Acreditările sunt stocate pe partea serverului și rotite.

  • Timeout, reîncercarea și comportamentul limită de rată sunt definite.

  • Cererile repetate sunt idempotente.

  • Conținutul generat intră într-o stare de revizuire.

  • Modificările sursei invalidează sau redeschid versiunea.

  • Navigarea lingvistică funcționează prin tastatură și tehnologie de asistență.

  • Monitorizarea acoperă eșecurile, cozile, latența și conținutul învechit.

Surse de referință

  1. Simple8 API documentație
  2. Simple8 modele de livrare
  3. Orientări privind accesibilitatea conținutului web (WCAG) 2.2

Pune ghidul în practică

Testați Simple8 cu conținut reprezentativ și utilizați lista de verificare pentru a planifica un flux de lucru de producție controlat.

Testează-ți propriul text