GS1 Resolveri testikomplekt: DPP-linkide töökindluse kontroll enne kasutuselevõttu

QR-kood, mis avab brauseris lehe, ei tõesta veel Resolveri töökindlust. GS1 Digital Linki Resolveri puhul on oluline täielik HTTP-käitumine: milliseid identifikaatoreid aktsepteeritakse? Milline sihtkoht on vaikimisi? Kas teenus edastab masinloetava lingikogumi? Kas brauseripäringud teistelt domeenidelt toimivad? Ja kas vigased või kättesaamatud päringud annavad õige veateate?

Alates 16. jaanuarist 2026 on saadaval GS1 Conformant Resolveri standard 1.2.0. Sellega seotud avalik GS1 testikomplekt on nüüdseks stabiilne; selle koodi uuendati viimati 29. juunil 2026. Nii saab abstraktsest standardist teha konkreetse vastuvõtutesti. Selles artiklis näitame, mida tuleks enne kasutuselevõttu kontrollida, millised on testikomplekti piirangud ja millised tõendid peaksid kuuluma tehnilisse heakskiitu.

Edukas skannimine on alles algus

Üks GS1 Digital Link sisaldab GS1-identifikaatorit HTTPS-URI-s. Resolver seob selle identifikaatori ühe või mitme ressursiga, näiteks tootelehe, juhendi, andmelehe või programmeerimisliidesega. Meie alusartiklis selgitatakse GS1 Digital Linki Resolverit elava näite abil. Tootmiskasutusse lubamiseks ei piisa siiski edukast standardse suunamise testist.

Resolveri standard 1.2.0 nõuab muu hulgas HTTPS-i, GET-, HEAD- ja OPTIONS-meetodite tuge, Cross-Origin Resource Sharingut (CORS), tuvastatavat vaikelingi ning lingikogumi väljundit. linkType=linkset korral või application/linkset+json Accept-päise puhul ei tohi Resolver ümber suunata. Selle asemel peab ta tagastama olemasolevad tüübitud lingid eraldiseisva esitusena.

See eristus on oluline: inimkasutaja brauseritee võib toimida, samal ajal kui masinjuurdepääs, keel, lingitüübid või veajuhtumid on katki. Just sellised kõrvalekalded jäävad puhta skannimistesti puhul märkamatuks.

Vastuvõtuplaan seitsmes etapis

1. Määrake esinduslikud test-URI-d

Ärge alustage ühest näidistootest. Koostage väike versioonitud testikogum:

vähemalt üks kehtiv identifikaator iga toetatud GS1 esmase võtme kohta;
üks GTIN-juht ilma kvalifikaatorita;
partii või seerianumbriga juhtumid, kui sellist detailsust toetatakse;
süntaktiliselt vigane identifikaator;
kehtiv, kuid tundmatu identifikaator;
tuntud identifikaator ilma küsitud lingitüübita.

Standard lubab Resolveril toetada ainult osa GS1 esmastest võtmetest. Iga toetatud esmase võtme puhul tuleb aga selle kvalifikaatoreid ja andmeatribuute täielikult töödelda. Seetõttu peab testikogum vastama tegelikult deklareeritud võimekusele, mitte üldisele turundusväitele.

2. Kontrollige standardset ümbersuunamist ja meetodeid

Testige tavalist päringut esmalt ilma eripäisteta. Oodata on deterministlikku vaikelingi. Seejärel testige HEAD- ja OPTIONS-päringuid: HEAD ei tohi kasutada GET-ist erinevat marsruutimisloogikat ning OPTIONS peab pakutavad meetodid arusaadavalt teatavaks tegema.

Minimaalne käsitsi tehtav test näeb välja selline:

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

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

Dokumenteerige olekukood, Location, vahemälupäised ja ümbersuunamiste arv. Ümbersuunamiste tsükkel, juhuslik sihtkoht või meetoditi erinev teekond on kasutuselevõtu takistus isegi siis, kui nutitelefon lõpuks lehe kuvab.

3. Küsige veebilehe asemel lingikogumit

Kõige olulisem masinkontroll on lingikogum:

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

RFC 9264 määratleb application/linkset+json-i tüübitud veeb linkide hulga eraldiseisva JSON-esitusena. GS1 täpsustab lepingut: väljund peab läbima valideerimise versiooni 1.2.0 normatiivse lingikogumi skeemi vastu. Seetõttu kontrollige mitte ainult JSON-i tagastamist, vaid ka meediatüüpi, skeemi, absoluutseid siht-URI-sid, ankrut ja lingirelatsioone.

Eriti petlikud on vormiliselt kehtivad, kuid sisuliselt valed lingikogumid: näiteks juhend tooteteabe lehe lingitüübi all või seerianumbriga seotud sihtkoht GTIN-tasemel. Seetõttu peavad skeemi valideerimine ja valdkondlikud testandmed käima käsikäes.

4. Kontrollige Resolveri kirjeldust

Nõuetele vastav Resolver pakub aadressil /.well-known/gs1resolver masinloetavat kirjeldust. See sisaldab muu hulgas Resolveri põhiaadressi ja toetatud esmaseid võtmeid. Fail peab läbima valideerimise GS1 Resolveri kirjeldusfailide skeemi vastu.

See test aitab vältida levinud ebakõla: teenus võib pakkuda rohkem või vähem, kui enesekirjeldus väidab. Seetõttu lisage vastuvõttu nii skeemi valideerimine kui ka võrdlus tegelike testjuhtumitega.

5. Testige CORS-i ja sisu läbirääkimist

CORS ei ole mugavusfunktsioon. Standard nõuab seda selleks, et brauseripõhised rakendused saaksid Resolverile domeenideüleselt päringuid teha. Testige vähemalt üht lubatud brauseri päritolu ning eelkontrolli teekonda. Kontrollige lisaks, kas Accept: application/linkset+json ja linkType=linkset annavad ühtsed tulemused.

Lisage negatiivne test toetamata meediatüübi jaoks. Teenus, mis saadab sõltumata Accept-päisest alati HTML-i, on inimestele küll kättesaadav, kuid masinloetavuse seisukohast ebausaldusväärne.

6. Katke keel, kontekst ja detailsus

Standard näeb ette Accept-Language-i ning päringuparameetri context kasutamise, et eristada mitme sobiva lingi vahel. Iga Resolver ei pea pakkuma kõiki variante. Kui keelt või konteksti toetatakse, peavad valikureeglid olema aga korratavad.

Testige seetõttu olemasolevat keelt, puuduvat keelt ja määratletud varuvalikute järjekorda. Sama põhimõte kehtib GTIN, partii ja seerianumbri puhul: täpsem identifikaator võib arvesse võtta kõrgema taseme asjakohaseid linke, kuid ei tohi valdkondlikku seost hägustada. Fikseerige eeldatav linkide hulk testandmetena; üksnes järjestusele tuginevad hetktõmmistestid on liiga haprad.

7. Eristage vigu semantiliselt

Veakoodid on lepingu osa. Resolveri standard näeb süntaktiliselt vigaste GS1-identifikaatorite puhul ette HTTP 400-ga vastuse. Kui küsitakse konkreetset kättesaamatut lingitüüpi, ei ole ümbersuunamine vaikesihtkohta õige vastus. Need juhtumid tuleb eristada tundmatust, kuid süntaktiliselt kehtivast identifikaatorist.

Kontrollige ka, et veavastused ei avaldaks sisemisi üksikasju, tokeneid ega pinujälgi ning et GET-, HEAD- ja brauseripõhised päringud säilitaksid sama semantika. Ilus HTML-veadokument ei saa vale olekukoodi heastada.

GS1 testikomplekti õige kasutamine

Avalik testikomplekt võtab vastu Digital Linki URI ja kontrollib käitumist Resolveri 1.2.0 vastu. See sobib hästi sõltumatuks suitsu- ja vastavuskontrolliks. Salvestage kasutuselevõtu jaoks testi kuupäev, testitud URI, standardi versioon, tulemus ja vajaduse korral korratavad veajuhtumid.

Komplekt ei asenda siiski teie enda regressiooniteste. GS1 juhib sõnaselgelt tähelepanu sellele, et praegu ei kontrollita tihendamist. Kui teie Resolver töötleb EPC binaarsõnesid või muid tihendatud vorme, vajate nende jaoks eraldi testvektoreid. Samuti ei tunne avalik komplekt teie valdkondlikke lingitüüpe ega autoriseerimise, rentnike või kättesaadavuse nõudeid.

Töökindel protsess ühendab seega kolm taset:

avalik GS1 komplekt välise vastavuskontrollina;
lingikogumi ja Resolveri kirjelduse skeemitestid CI-s;
enda otsast lõpuni testid tegelike identifikaatorite, rollide, keelte ja tõrgete jaoks.

Mida lisada kasutuselevõtu tõendisse

Vastuvõtt on korratav alles siis, kui tulemus pole nähtav ainult brauseris, vaid on ka dokumenteeritud. Kasutuselevõtu tõend peaks sisaldama vähemalt standardi ja komplekti versiooni, testi aega, sihtkeskkonda, test-URI-sid, eeldatavaid lingitüüpe, HTTP-tulemusi, skeemi valideerimist, CORS-i kontrolli ja teadaolevaid erandeid.

Automatiseerige stabiilsed osad CI-s, kuid tehke enne iga olulist Resolveri muudatust ka sihipärane väline test avaliku komplekti vastu. Nii saab väitest „QR-kood avaneb” kontrollitav väide identiteedi, marsruutimise ja masinloetava tooteteabe kohta.