Testna zbirka za razreševalnik GS1: DPP-povezave zanesljivo preverite pred uvedbo v produkcijo

Koda QR, ki v brskalniku odpre stran, še ne dokazuje zanesljivega razreševalnika. Pri razreševalniku za GS1-povezave je pomembno celotno vedenje HTTP: Kateri identifikatorji so sprejeti? Kateri cilj je privzeti? Ali storitev vrne strojno berljivo množico povezav? Ali dostopi brskalnika prek drugih domen delujejo? In ali neveljavne ali nedosegljive zahteve vrnejo pravilno napako?

Od 16. januarja 2026 je na voljo GS1-Conformant Resolver Standard 1.2.0. Pripadajoča javna testna zbirka GS1 zdaj velja za stabilno; njena koda je bila nazadnje posodobljena 29. junija 2026. Tako lahko abstrakten standard spremenite v konkreten prevzemni preizkus. Ta prispevek prikazuje, kaj je treba preveriti pred uvedbo v produkcijo, kje so meje testne zbirke in kateri dokazi sodijo v tehnično odobritev.

Uspešno skeniranje je šele začetek

En GS1 Digital Link vsebuje GS1-identifikator v URI-ju HTTPS. Razreševalnik ta identifikator poveže z enim ali več viri, na primer s stranjo izdelka, navodili, podatkovnim listom ali programskim vmesnikom. Naš uvodni prispevek pojasnjuje razreševalnik GS1-povezav s praktičnim primerom. Za odobritev produkcije uspešna privzeta preusmeritev še ni dovolj.

Standard za razreševalnike 1.2.0 med drugim zahteva HTTPS, podporo za GET, HEAD in OPTIONS, Cross-Origin Resource Sharing (CORS), prepoznaven privzeti link ter izhod v obliki množice povezav. Pri linkType=linkset ali glavi Accept application/linkset+json razreševalnik ne sme preusmeriti. Namesto tega mora vrniti razpoložljive tipizirane povezave kot samostojno predstavitev.

Ta ločitev je pomembna: pot človeškega uporabnika v brskalniku lahko deluje, medtem ko so strojni dostop, jezik, tipi povezav ali napake nedelujoči. Prav takšna odstopanja pri zgolj preizkusu s skeniranjem ostanejo neopažena.

Načrt prevzema v sedmih korakih

1. Določite reprezentativne testne URI-je

Ne začnite z enim samim vzorčnim izdelkom. Sestavite majhno, različicno zbirko testov:

vsaj en veljaven identifikator za vsak podprti primarni ključ GS1;
primer GTIN brez kvalifikatorja;
primere s serijo ali serijsko številko, če je ta granularnost podprta;
skladenjsko neveljaven identifikator;
veljaven, vendar neznan identifikator;
znan identifikator brez zahtevanega tipa povezave.

Standard razreševalniku dovoljuje podporo le podmnožici primarnih ključev GS1. Za vsak podprti primarni ključ pa mora v celoti obdelati njegove kvalifikatorje in podatkovne atribute. Zato se mora testna množica ujemati z dejansko deklarirano zmogljivostjo, ne s splošno trženjsko izjavo.

2. Preverite privzeto preusmeritev in metode

Najprej preizkusite običajen klic brez posebnih glav. Pričakovan je determinističen privzeti link. Nato sledita HEAD in OPTIONS: HEAD ne sme uporabljati drugačne logike usmerjanja kot GET, OPTIONS pa mora pregledno prikazati podprte metode.

Minimalni ročni preizkus je videti tako:

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

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

Dokumentirajte statusno kodo, Location, glave predpomnilnika in število preusmeritev. Zanka preusmeritev, naključen cilj ali pot, ki se razlikuje glede na metodo, je napaka pri odobritvi, tudi če pametni telefon na koncu prikaže stran.

3. Zahtevajte množico povezav namesto spletne strani

Najpomembnejši strojni preizkus je množica povezav:

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

RFC 9264 opredeljuje application/linkset+json kot samostojno JSON-predstavitev množice tipiziranih spletnih povezav. GS1 pogodbo zaostruje: izhod mora biti veljaven glede na normativno shemo množice povezav za različico 1.2.0. Zato ne preverjajte le, ali je vrnjen JSON, temveč tudi vrsto medija, shemo, absolutne ciljne URI-je, sidro in relacije povezav.

Še posebej zahrbtne so formalno veljavne, vendar strokovno napačne množice povezav: na primer priročnik pod tipom povezave za stran z informacijami o izdelku ali cilj, povezan s serijsko številko, na ravni GTIN. Preverjanje sheme in strokovne testne priprave zato sodijo skupaj.

4. Preverite opis razreševalnika

Skladen razreševalnik na naslovu /.well-known/gs1resolver zagotavlja strojno berljiv opis. Ta med drugim navaja koren razreševalnika in podprte primarne ključe. Datoteka mora biti veljavna glede na shemo GS1 za datoteke z opisi razreševalnika.

Ta preizkus preprečuje pogosto nedoslednost: storitev zmore več ali manj, kot trdi njen opis. Zato v prevzem vključite tako preverjanje sheme kot primerjavo z dejanskimi testnimi primeri.

5. Preizkusite CORS in pogajanje o vsebini

CORS ni zgolj priročna funkcija. Standard ga zahteva, da lahko brskalniške aplikacije razreševalnik dosežejo prek različnih domen. Preizkusite vsaj en dovoljen izvor brskalnika in pot predhodne zahteve. Poleg tega preverite, ali Accept: application/linkset+json in linkType=linkset vrneta skladne rezultate.

Dodajte negativen preizkus za nepodprto vrsto medija. Storitev, ki ne glede na glavo Accept vedno pošlje HTML, je sicer dostopna ljudem, vendar ni zanesljivo strojno berljiva.

6. Zajmite jezik, kontekst in granularnost

Standard predvideva Accept-Language in parameter poizvedbe context kot sredstvi za razlikovanje med več ustreznimi povezavami. Ni treba, da vsak razreševalnik ponuja vsako različico. Če podpira jezik ali kontekst, pa morajo biti pravila izbire ponovljiva.

Zato preizkusite obstoječi jezik, neobstoječi jezik in določeno zaporedje nadomestnih izbir. Za GTIN, serijo in serijsko številko velja isto načelo: natančen identifikator lahko upošteva ustrezne povezave višjih ravni, ne da bi zabrisal strokovno razvrstitev. Pričakovano množico povezav zabeležite kot testno pripravo; zgolj posnetkovni preizkusi vrstnega reda so preveč krhki.

7. Pomensko razlikujte napake

Kode napak so del pogodbe. Standard za razreševalnike predvideva sporočilo HTTP 400 za skladenjsko neveljavne GS1-identifikatorje. Če je zahtevan konkreten, nedosegljiv tip povezave, preusmeritev na privzeti cilj ni pravi odgovor. Takšne primere je treba ločiti od neznanega, vendar skladenjsko veljavnega identifikatorja.

Preverite tudi, ali odgovori z napakami ne razkrivajo notranjih podrobnosti, žetonov ali izpisov sklada ter ali GET, HEAD in zahteve iz brskalnika ohranjajo isto semantiko. Lep dokument HTML z napako ne more popraviti napačne statusne kode.

Pravilna uporaba testne zbirke GS1

Javna testna zbirka sprejme URI povezave in preveri vedenje glede na razreševalnik 1.2.0. Primerna je kot neodvisno preverjanje osnovnega delovanja in skladnosti. Za odobritev shranite datum preizkusa, preizkušeni URI, različico standarda, rezultat in po potrebi ponovljive primere napak.

Zbirka pa ne nadomesti lastne regresije. GS1 izrecno opozarja, da trenutno ne preverja stiskanja. Če vaš razreševalnik obdeluje binarne nize EPC ali druge stisnjene oblike, zanje potrebujete ločene testne vektorje. Javna zbirka prav tako ne pozna vaših strokovnih tipov povezav, zahtev glede avtorizacije, najemnikov ali razpoložljivosti.

Zanesljiv proces zato združuje tri ravni:

javna zbirka GS1 kot zunanje preverjanje skladnosti;
preizkusi shem za množico povezav in opis razreševalnika v CI;
lastni celoviti preizkusi za dejanske identifikatorje, vloge, jezike in izpade.

Kaj sodi v dokazilo o odobritvi

Prevzem je ponovljiv šele, ko rezultat ni le viden v brskalniku, temveč tudi dokumentiran. Dokazilo o odobritvi mora vsebovati vsaj različico standarda in zbirke, čas preizkusa, ciljno okolje, testne URI-je, pričakovane tipe povezav, rezultate HTTP, preverjanje sheme, preverjanje CORS in znane izjeme.

Stabilne dele avtomatizirajte v CI, vendar pred vsako pomembno spremembo razreševalnika izvedite tudi usmerjen zunanji preizkus javne zbirke. Tako »koda QR se odpre« postane preverljiva trditev o identiteti, usmerjanju in strojno berljivih informacijah o izdelku.