Cum tratăm zilele fără curs BNR (weekend și sărbători) fără erori de produs
Context
Sistemele care consumă cursuri valutare oficiale se lovesc inevitabil de o realitate operațională: nu există publicare nouă în fiecare zi calendaristică. Weekend-urile și unele sărbători produc „goluri” normale în serie. Dacă produsul tratează aceste zile ca excepții necontrolate, utilizatorul primește fie erori inutile, fie mesaje confuze. Dacă produsul tratează explicit lipsa de date ca scenariu prevăzut, experiența rămâne stabilă.
În Convertesc.ro, această problemă nu este abordată prin „ghicit” sau prin inventarea unor rate. Logica corectă este revenirea la ultimul curs disponibil anterior datei cerute, cu marcarea clară a faptului că s-a folosit această soluție. Astfel păstrăm consecvența numerică și transparența. Utilizatorul știe ce primește, iar dezvoltatorul poate reconstitui ușor decizia.
Subiectul este critic și pentru SEO, și pentru încredere. Multe căutări apar exact în weekend, când utilizatorii verifică o pereche înainte de luni. Dacă pagina răspunde coerent cu „ultimul curs disponibil”, produsul rămâne util în momentele în care competiția afișează erori sau date ambigue.
Cum funcționează
Modelul recomandat are trei pași. Pasul unu: verifici dacă data cerută are rate disponibile. Pasul doi: dacă nu are, cauți cea mai apropiată dată anterioară cu date valide. Pasul trei: returnezi răspunsul și marchezi explicit că s-a revenit la o zi anterioară. În API, această decizie este transmisă prin câmpuri care păstrează contextul: data cerută, data efectiv servită și indicatorul fallback_applied.
Aceeași logică trebuie să fie vizibilă și în interfață. Când utilizatorul selectează o zi fără publicare, produsul nu ar trebui să pară „blocat”. Mai util este să continue conversia pe ultimul set valid și să afișeze transparent data de referință. Astfel, utilizatorul poate compara cu zilele anterioare fără să creadă că site-ul a eșuat.
Pe partea de integrare, echipele care consumă endpoint-uri istorice trebuie să decidă dacă acceptă revenirea automată la ultima zi disponibilă sau dacă cer strict data exactă. Aici apare utilitatea parametrului strict_date: permite un control diferit în funcție de scenariu. Pentru raportare robustă, revenirea automată este practică. Pentru un audit punctual, data exactă poate fi obligatorie.
Dacă ai nevoie de context API detaliat, vezi articolul despre cursul curent, cursul istoric și strict_date și articolul despre monitorizare și verificări de stare.
Exemplu practic
Presupunem că o aplicație solicită endpoint-ul istoric pentru o dată de duminică. Comportamentul robust arată așa:
curl "https://convertesc.ro/api/v1/historical/2026-02-22?base=EUR&symbols=RON"
Răspunsul util pentru integrare ar trebui să păstreze semnalul că s-a revenit la o zi anterioară:
{
"requested_date": "2026-02-22",
"date": "2026-02-20",
"fallback_applied": true,
"base": "EUR",
"rates": {
"RON": 4.97
}
}
În acest scenariu, aplicația care consumă API-ul poate:
- afișa valoarea pentru conversie;
- menționa explicit data efectivă;
- nota în jurnale faptul că s-a folosit o dată anterioară, pentru audit intern.
Aceeași abordare reduce erorile de suport. În loc de mesajul vag „endpoint-ul nu merge”, primești un comportament determinist și ușor de documentat. În plus, poți sincroniza ușor această logică cu interfața principală, astfel încât experiența să fie identică între site și API. Pentru utilizatorii care urmăresc perechi, articolul ghidul perechilor valutare completează foarte bine această parte.
Greșeli frecvente
Prima greșeală este returnarea unui 404 sau 500 pentru o zi fără publicare, deși date anterioare valide există. Tehnic, nu e „lipsă totală de resursă”, ci o situație de calendar ce poate fi tratată predictibil. Afișarea unei erori dure degradează inutil experiența.
A doua greșeală este revenirea „din tăcere” la o dată anterioară, fără indicator în răspuns sau în interfață. Deși numeric rezultatul poate părea corect, lipsa semnalului rupe trasabilitatea. Când apare un audit sau un incident de comparație, echipa pierde timp încercând să reconstruiască manual ce dată a fost folosită efectiv.
A treia greșeală este activarea lui strict_date ca opțiune implicită în toate cazurile. În multe aplicații orientate spre continuitate, această alegere produce prea multe „goluri” în grafice și conversii. O variantă mai sănătoasă este revenirea automată la ultima zi disponibilă, iar modul strict să fie activat explicit.
A patra greșeală este testarea insuficientă pe intervale lungi, inclusiv în perioade cu mai multe zile libere legate. Nu e suficient un singur test de weekend; trebuie verificate scenarii consecutive cu 2-4 zile fără publicare și comportamentul la reluarea unei zile lucrătoare. Articolul despre monitorizare și verificări de stare detaliază cum poți operaționaliza această verificare.
Ca hub tehnic, leagă această logică de api curs valutar bnr json: latest și historical, de bnr api cursor pagination dates și de bnr api health endpoint.
Concluzie
Zilele fără curs BNR nu trebuie tratate ca anomalii, ci ca parte normală a domeniului. Revenirea explicită la ultima zi disponibilă menține produsul util, evită erorile artificiale și păstrează încrederea utilizatorului. Cheia este transparența: aceeași logică trebuie comunicată în API, în interfață și în documentație.
Pentru echipele tehnice, combinația recomandată este simplă: revenire automată pentru continuitate, strict_date pentru cazurile care cer exactitate strictă, plus monitorizare activă a fluxului de date. Dacă vrei să extinzi implementarea, continuă cu articolul despre cursul curent și cursul istoric și cu articolul despre paginarea cu cursor.