Testni paket GS1 Resolvera: DPP-veze pouzdano provjeriti prije puštanja u rad

QR-kod koji u pregledniku otvara stranicu još nije dokaz pouzdanog Resolvera. Za GS1-Digital-Link-Resolver važno je cjelokupno ponašanje HTTP-a: Koji se identifikatori prihvaćaju? Koje je odredište zadano? Isporučuje li usluga strojno čitljiv skup poveznica? Funkcionira li pristup iz preglednika preko drugih domena? I prijavljuju li nevažeći ili nedostupni zahtjevi ispravnu pogrešku?

Od 16. siječnja 2026. dostupan je GS1-Conformant Resolver Standard 1.2.0. Povezani javni GS1-testni paket u međuvremenu se smatra stabilnim; njegov je kod posljednji put ažuriran 29. lipnja 2026. Tako se apstraktna norma može pretvoriti u konkretan prihvatni test. Ovaj članak pokazuje što treba provjeriti prije puštanja u rad, gdje testni paket ima ograničenja i koji dokazi trebaju biti dio tehničkog odobrenja.

Uspješno skeniranje samo je početak

Jedan GS1 Digital Link sadrži GS1-identifikator u HTTPS-URI-ju. Resolver povezuje taj identifikator s jednim ili više resursa, primjerice stranicom proizvoda, uputama, podatkovnim listom ili programskim sučeljem. Naš uvodni članak objašnjava GS1-Digital-Link-Resolver s primjerom uživo. Za odobrenje produkcijskog sustava uspješno standardno preusmjeravanje ipak nije dovoljno.

Resolver Standard 1.2.0 između ostalog zahtijeva HTTPS, podršku za GET, HEAD i OPTIONS, Cross-Origin Resource Sharing (CORS), prepoznatljivu zadanu poveznicu te izlazni skup poveznica. Kod linkType=linkset ili zaglavlja Accept application/linkset+json Resolver ne smije preusmjeravati. Umjesto toga mora vratiti dostupne tipizirane poveznice kao samostalnu reprezentaciju.

Ovo je razdvajanje važno: putanja za ljudski preglednik može funkcionirati, dok pristup strojeva, jezik, vrste poveznica ili slučajevi pogrešaka mogu biti neispravni. Upravo takva odstupanja ostaju nevidljiva pri samom testiranju skeniranjem.

Plan prihvata u sedam koraka

1. Definirati reprezentativne testne URI-je

Nemojte početi s jednim jedinim oglednim proizvodom. Sastavite malu, verzioniranu zbirku testova:

najmanje jedan valjani identifikator za svaki podržani GS1-primarni ključ;
slučaj GTIN bez kvalifikatora;
slučajeve s partijom ili serijskim brojem, ako je ta granularnost podržana;
sintaktički nevažeći identifikator;
valjani, ali nepoznati identifikator;
poznati identifikator bez tražene vrste poveznice.

Norma dopušta Resolveru da podržava samo podskup GS1-primarnih ključeva. Međutim, za svaki podržani primarni ključ njegovi kvalifikatori i podatkovni atributi moraju se u cijelosti obraditi. Zato testni skup mora odgovarati stvarno deklariranim mogućnostima, a ne općoj marketinškoj tvrdnji.

2. Provjeriti standardno preusmjeravanje i metode

Najprije testirajte uobičajeni poziv bez posebnih zaglavlja. Očekuje se deterministička zadana poveznica. Zatim slijede HEAD i OPTIONS: HEAD ne smije koristiti drukčiju logiku usmjeravanja od GET, a OPTIONS mora razumljivo prikazati ponuđene metode.

Minimalni ručni test izgleda ovako:

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

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

Dokumentirajte statusni kôd, Location, zaglavlja predmemorije i broj preusmjeravanja. Petlja preusmjeravanja, nasumično odredište ili putanja koja se razlikuje ovisno o metodi pogreška je pri odobrenju, čak i ako pametni telefon naposljetku prikaže stranicu.

3. Zatražiti skup poveznica umjesto web-stranice

Najvažnija strojna provjera jest skup poveznica:

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

RFC 9264 definira application/linkset+json kao samostalnu JSON-reprezentaciju skupa tipiziranih web-poveznica. GS1 dodatno pooštrava ugovor: izlaz mora biti valjan prema normativnoj shemi skupa poveznica za verziju 1.2.0. Zato ne provjeravajte samo vraća li se JSON, nego i vrstu medija, shemu, apsolutne odredišne URI-jeve, sidro i relacije poveznica.

Posebno su podmukli formalno valjani, ali stručно pogrešni skupovi poveznica: primjerice priručnik pod vrstom poveznice za stranicu s informacijama o proizvodu ili odredište povezano sa serijskim brojem na razini GTIN. Validacija sheme i stručni fixturei zato pripadaju zajedno.

4. Provjeriti opis Resolvera

Sukladan Resolver na adresi /.well-known/gs1resolver stavlja na raspolaganje strojno čitljiv opis. On između ostalog navodi osnovu Resolvera i podržane primarne ključeve. Datoteka mora biti valjana prema GS1-shemi za datoteke opisa Resolvera.

Ovaj test sprječava čestu nedosljednost: usluga može podržavati više ili manje od onoga što navodi u vlastitom opisu. Zato u prihvat uključite i validaciju sheme i usporedbu sa stvarnim testnim slučajevima.

5. Testirati CORS i pregovaranje o sadržaju

CORS nije pogodnost. Norma ga zahtijeva kako bi aplikacije temeljene na pregledniku mogle pristupati Resolveru preko različitih domena. Testirajte barem jedan dopušteni origin preglednika i putanju za preflight. Provjerite i daju li Accept: application/linkset+json i linkType=linkset dosljedne rezultate.

Dodajte negativni test za nepodržanu vrstu medija. Usluga koja neovisno o zaglavlju Accept uvijek šalje HTML dostupna je ljudima, ali nije pouzdano strojno čitljiva.

6. Obuhvatiti jezik, kontekst i granularnost

Norma predviđa Accept-Language i parametar upita context kao sredstva za razlikovanje više odgovarajućih poveznica. Ne mora svaki Resolver nuditi svaku varijantu. Ako se jezik ili kontekst podržavaju, pravila odabira moraju biti ponovljiva.

Zato testirajte postojeći jezik, nepostojeći jezik i definirani redoslijed zamjenskih vrijednosti. Za GTIN, partiju i serijski broj vrijedi isto načelo: precizni identifikator smije uzeti u obzir relevantne poveznice viših razina, a da se pritom ne zamagli stručna povezanost. Očekivani broj poveznica zabilježite kao fixture; čisti snapshot-testovi redoslijeda previše su krhki.

7. Semantički razlikovati pogreške

Kodovi pogrešaka dio su ugovora. Resolver Standard za sintaktički nevažeće GS1-identifikatore predviđa poruku s HTTP-om 400. Ako se zatraži konkretna, nedostupna vrsta poveznice, preusmjeravanje na zadano odredište upravo nije ispravan odgovor. Takve slučajeve treba razlikovati od nepoznatog, ali sintaktički valjanog identifikatora.

Provjerite i da odgovori na pogreške ne otkrivaju interne pojedinosti, tokene ili tragove stoga te da GET, HEAD i zahtjevi iz preglednika zadržavaju istu semantiku. Privlačan HTML-dokument s pogreškom ne može nadoknaditi pogrešan statusni kôd.

Ispravno koristiti GS1-testni paket

Javni testni paket prima Digital-Link-URI i provjerava ponašanje prema Resolveru 1.2.0. Dobro je prikladan kao neovisna provjera osnovne funkcionalnosti i sukladnosti. Za odobrenje sačuvajte datum testa, testirani URI, verziju standarda, rezultat i, prema potrebi, ponovljive slučajeve pogrešaka.

Međutim, paket ne zamjenjuje vlastitu regresiju. GS1 izričito navodi da trenutačno ne provjerava kompresiju. Ako vaš Resolver obrađuje EPC-binarne nizove ili druge komprimirane oblike, za njih su potrebni zasebni testni vektori. Javni paket također ne poznaje vaše stručne vrste poveznica ni vaše zahtjeve za autorizacijom, više klijenata ili dostupnošću.

Pouzdan proces stoga kombinira tri razine:

javni GS1-paket kao vanjsku provjeru sukladnosti;
testove sheme za skup poveznica i opis Resolvera u CI-ju;
vlastite end-to-end testove za stvarne identifikatore, uloge, jezike i ispade.

Što treba sadržavati dokaz o odobrenju

Prihvat je ponovljiv tek kada rezultat nije samo vidljiv u pregledniku, nego je i dokumentiran. Dokaz o odobrenju trebao bi sadržavati barem verziju standarda i paketa, vrijeme testiranja, ciljno okruženje, testne URI-jeve, očekivane vrste poveznica, HTTP-rezultate, validaciju sheme, provjeru CORS-a i poznate iznimke.

Stabilne dijelove automatizirajte u CI-ju, ali prije svake važne promjene Resolvera zadržite ciljano vanjsko pokretanje protiv javnog paketa. Tako „QR-kod se otvara” postaje provjerljiva tvrdnja o identitetu, usmjeravanju i strojno čitljivim informacijama o proizvodu.