Suita de testare a Resolverului GS1: DPP-Link-uri verificate riguros înainte de lansare

Un cod QR care deschide o pagină în browser nu dovedește încă robustețea unui resolver. Pentru un resolver de legături digitale GS1 contează comportamentul HTTP complet: ce identificatori sunt acceptați? Care este destinația implicită? Oferă serviciul un set de linkuri lizibil automat? Funcționează accesările din browser de pe alte domenii? Și raportează cererile invalide sau indisponibile eroarea corectă?

Începând cu 16 ianuarie 2026, este disponibil GS1-Conformant Resolver Standard 1.2.0. Suita publică de testare GS1 aferentă este între timp considerată stabilă; codul său a fost actualizat ultima dată la 29 iunie 2026. Astfel, un standard abstract poate fi transformat într-un test concret de acceptanță. Acest articol arată ce trebuie verificat înainte de lansare, care sunt limitele suitei de testare și ce dovezi trebuie incluse într-o aprobare tehnică.

O scanare reușită este doar începutul

Un GS1 Digital Link conține un identificator GS1 într-un URI HTTPS. Resolverul asociază acest identificator cu una sau mai multe resurse, de exemplu o pagină de produs, instrucțiuni, o fișă tehnică sau o interfață de programare. Articolul nostru introductiv explică resolverul pentru legături digitale GS1 printr-un exemplu live. Pentru aprobarea în producție, o redirectare standard reușită nu este însă suficientă.

Standardul pentru resolver 1.2.0 impune, printre altele, HTTPS, suport pentru GET, HEAD și OPTIONS, Cross-Origin Resource Sharing (CORS), un link implicit identificabil și o ieșire de tip set de linkuri. Pentru linkType=linkset sau antetul Accept application/linkset+json, resolverul nu trebuie să redirecționeze. În schimb, acesta trebuie să returneze linkurile tipizate disponibile ca reprezentare independentă.

Această separare este importantă: fluxul uman din browser poate funcționa, în timp ce accesul automat, limba, tipurile de linkuri sau cazurile de eroare sunt defecte. Tocmai astfel de abateri rămân invizibile la un simplu test de scanare.

Planul de acceptanță în șapte pași

1. Stabiliți URI-uri de test reprezentative

Nu începeți cu un singur produs-model. Alcătuiți o colecție mică și versionată de teste:

cel puțin un identificator valid pentru fiecare cheie primară GS1 acceptată;
un caz de GTIN fără calificator;
cazuri cu lot sau număr de serie, dacă este acceptat acest nivel de granularitate;
un identificator invalid din punct de vedere sintactic;
un identificator valid, dar necunoscut;
un identificator cunoscut fără tipul de link solicitat.

Standardul permite unui resolver să accepte doar un subset al cheilor primare GS1. Pentru fiecare cheie primară acceptată trebuie însă procesați complet calificatorii și atributele de date ale acesteia. De aceea, setul de teste trebuie să corespundă capacității declarate efectiv, nu unei afirmații de marketing generale.

2. Verificați redirectarea implicită și metodele

Testați mai întâi apelul normal fără antete speciale. Se așteaptă un link implicit determinist. Apoi urmați HEAD și OPTIONS: HEAD nu trebuie să utilizeze o logică de rutare diferită de GET, iar OPTIONS trebuie să facă metodele oferite ușor de înțeles.

Un test manual minimal arată astfel:

curl -sS -D - -o /dev/null \
  "https://id.gs1.org/01/09506000134352"

curl -sS -I \
  "https://id.gs1.org/01/09506000134352"

Documentați codul de stare, Location, antetele de cache și numărul de redirectări. O buclă de redirectare, o destinație aleatorie sau un traseu diferit în funcție de metodă reprezintă o eroare de aprobare, chiar dacă un smartphone afișează în cele din urmă o pagină.

3. Solicitați un set de linkuri în locul unei pagini web

Cea mai importantă verificare automată este setul de linkuri:

curl -sS \
  -H "Accept: application/linkset+json" \
  "https://id.gs1.org/01/09506000134352"

RFC 9264 definește application/linkset+json ca reprezentare JSON independentă a unui ansamblu de linkuri web tipizate. GS1 înăsprește cerințele: rezultatul trebuie să fie validat conform schemei normative pentru seturi de linkuri, versiunea 1.2.0. Prin urmare, verificați nu doar dacă este returnat JSON, ci și tipul media, schema, URI-urile țintă absolute, ancora și relațiile dintre linkuri.

Deosebit de înșelătoare sunt seturile de linkuri valide formal, dar incorecte din punct de vedere tehnic: de exemplu, un manual sub tipul de link destinat unei pagini cu informații despre produs sau o destinație asociată seriei la nivelul GTIN. De aceea, validarea schemei și fixture-urile tehnice trebuie utilizate împreună.

4. Controlați descrierea resolverului

Un resolver conform pune la dispoziție la /.well-known/gs1resolver o descriere lizibilă automat. Aceasta menționează, printre altele, rădăcina resolverului și cheile primare acceptate. Fișierul trebuie validat conform schemei GS1 pentru fișierele de descriere a resolverului.

Acest test previne o inconsistență frecventă: serviciul poate oferi mai mult sau mai puțin decât afirmă propria descriere. Includeți, așadar, atât validarea schemei, cât și o comparație cu cazuri de test reale în cadrul acceptanței.

5. Testați CORS și negocierea conținutului

CORS nu este un element de confort. Standardul îl impune pentru ca aplicațiile bazate pe browser să poată accesa resolverul de pe alte domenii. Testați cel puțin o origine de browser permisă și traseul de preflight. Verificați, de asemenea, dacă Accept: application/linkset+json și linkType=linkset oferă rezultate consecvente.

Adăugați un test negativ pentru un tip media neacceptat. Un serviciu care trimite întotdeauna HTML, indiferent de antetul Accept, este accesibil oamenilor, dar nu poate fi citit automat în mod fiabil.

6. Acoperiți limba, contextul și granularitatea

Standardul prevede Accept-Language și parametrul de interogare context ca mijloace de diferențiere între mai multe linkuri potrivite. Nu orice resolver trebuie să ofere fiecare variantă. Dacă sunt acceptate limba sau contextul, regulile de selecție trebuie însă să fie reproductibile.

Testați, prin urmare, o limbă disponibilă, una indisponibilă și o ordine de rezervă definită. Pentru GTIN, lot și număr de serie se aplică același principiu: un identificator mai specific poate lua în considerare linkuri relevante de la niveluri superioare, fără a estompa asocierea tehnică. Notați numărul așteptat de linkuri ca fixture; testele Snapshot bazate exclusiv pe ordine sunt prea fragile.

7. Diferențiați semantic erorile

Codurile de eroare fac parte din contract. Standardul pentru resolver prevede, pentru identificatorii GS1 invalizi sintactic, un răspuns cu HTTP 400. Dacă este solicitat un anumit tip de link indisponibil, redirectarea către destinația implicită nu este răspunsul corect. Astfel de cazuri trebuie diferențiate de un identificator necunoscut, dar valid sintactic.

Verificați și dacă răspunsurile de eroare nu dezvăluie detalii interne, tokenuri sau stack trace-uri și dacă GET, HEAD și cererile bazate pe browser păstrează aceeași semantică. Un document HTML de eroare aspectuos nu poate compensa un cod de stare incorect.

Utilizarea corectă a suitei de testare GS1

Suita publică de testare primește un URI de legătură digitală și verifică comportamentul în raport cu Resolver 1.2.0. Este potrivită ca verificare independentă de tip smoke și de conformitate. Pentru aprobare, salvați data testului, URI-ul verificat, versiunea standardului, rezultatul și, dacă este cazul, cazurile de eroare reproductibile.

Suita nu înlocuiește însă propria regresie. GS1 precizează explicit că, în prezent, nu verifică comprimarea. Dacă resolverul dumneavoastră procesează șiruri binare EPC sau alte forme comprimate, aveți nevoie de vectori de test separați. De asemenea, suita publică nu cunoaște tipurile dumneavoastră tehnice de linkuri și nici cerințele de autorizare, de multi-tenancy sau de disponibilitate.

Un proces robust combină, așadar, trei niveluri:

suita publică GS1 ca verificare externă de conformitate;
teste de schemă pentru setul de linkuri și descrierea resolverului în CI;
teste proprii end-to-end pentru identificatori reali, roluri, limbi și indisponibilități.

Ce trebuie să conțină dovada aprobării

O acceptanță este reproductibilă abia atunci când rezultatul nu este doar vizibil în browser, ci și documentat. Dovada aprobării ar trebui să includă cel puțin versiunea standardului și a suitei, momentul testării, mediul țintă, URI-urile de test, tipurile de linkuri așteptate, rezultatele HTTP, validarea schemei, verificarea CORS și excepțiile cunoscute.

Automatizați în CI componentele stabile, dar păstrați o rulare externă țintită împotriva suitei publice înaintea fiecărei modificări importante a resolverului. Astfel, afirmația „codul QR se deschide” devine o afirmație verificabilă despre identitate, rutare și informații despre produs lizibile automat.