GS1 Resolver tesztcsomag: DPP-hivatkozások megbízható ellenőrzése az élesítés előtt

Egy QR-kód, amely megnyit egy oldalt a böngészőben, még nem bizonyítja a resolver megbízható működését. Egy GS1 digitális hivatkozás-feloldó esetében a teljes HTTP-viselkedés számít: Mely azonosítókat fogadja el? Mi az alapértelmezett cél? A szolgáltatás géppel olvasható linkkészletet ad vissza? Működik a böngészőből indított hozzáférés más domaineken keresztül? És a hibás vagy nem elérhető kérések a megfelelő hibát jelzik?

2026. január 16. óta elérhető a GS1-Conformant Resolver Standard 1.2.0. A hozzá tartozó nyilvános GS1-tesztcsomag időközben stabilnak számít; a kódját legutóbb 2026. június 29-én frissítették. Így az absztrakt szabványból konkrét átvételi teszt készíthető. Ez a cikk bemutatja, mit érdemes ellenőrizni az élesítés előtt, hol vannak a tesztcsomag korlátai, és milyen bizonyítékoknak kell szerepelniük a műszaki jóváhagyásban.

A sikeres beolvasás csak a kezdet

Egy GS1 Digital Link HTTPS-URI-ban hordoz GS1-azonosítót. A resolver ezt az azonosítót egy vagy több erőforrással kapcsolja össze, például termékoldallal, útmutatóval, adatlappal vagy programozási felülettel. Alapozó cikkünk egy élő példán keresztül ismerteti a GS1 digitális hivatkozás-feloldót. Éles környezetbe engedéshez azonban nem elegendő a sikeres alapértelmezett átirányítás.

A Resolver Standard 1.2.0 többek között HTTPS-t, a GET, HEAD és OPTIONS támogatását, Cross-Origin Resource Sharinget (CORS), felismerhető alapértelmezett hivatkozást és linkkészlet-kimenetet ír elő. linkType=linkset vagy a application/linkset+json Accept-fejléc esetén a resolver nem irányíthat át. Ehelyett az elérhető, típusozott hivatkozásokat önálló reprezentációként kell visszaadnia.

Ez a különbségtétel fontos: az emberi böngészési útvonal működhet, miközben a gépi hozzáférés, a nyelv, a hivatkozástípusok vagy a hibás esetek hibásak. Az ilyen eltérések egy pusztán beolvasásra épülő teszt során rejtve maradnak.

Az átvételi terv hét lépésben

1. Reprezentatív teszt-URI-k meghatározása

Ne egyetlen mintatermékkel kezdjen. Állítson össze egy kis, verziózott tesztgyűjteményt:

legalább egy érvényes azonosító minden támogatott GS1-elsődleges kulcshoz;
egy GTIN-eset minősítő nélkül;
tétel- vagy sorozatszámot tartalmazó esetek, amennyiben ez a részletességi szint támogatott;
szintaktikailag érvénytelen azonosító;
érvényes, de ismeretlen azonosító;
ismert azonosító a kért hivatkozástípus nélkül.

A szabvány lehetővé teszi, hogy egy resolver a GS1-elsődleges kulcsoknak csak egy részhalmazát támogassa. Minden támogatott elsődleges kulcs esetében azonban annak minősítőit és adatattribútumait teljes körűen fel kell dolgozni. Ezért a tesztkészletnek a ténylegesen deklarált képességekhez, nem pedig általános marketingállításhoz kell igazodnia.

2. Az alapértelmezett átirányítás és a metódusok ellenőrzése

Először tesztelje a normál hívást különleges fejlécek nélkül. Determinisztikus alapértelmezett hivatkozás az elvárt eredmény. Ezt követi a HEAD és a OPTIONS: a HEAD nem használhat más útválasztási logikát, mint a GET, a OPTIONS-nak pedig áttekinthetővé kell tennie a kínált metódusokat.

Egy minimális manuális teszt így néz ki:

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

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

Dokumentálja az állapotkódot, a Location-t, a gyorsítótár-fejléceket és az átirányítások számát. Az átirányítási hurok, a véletlenszerű cél vagy a metódusonként eltérő útvonal jóváhagyási hiba, még akkor is, ha egy okostelefon végül megjelenít egy oldalt.

3. Weboldal helyett linkkészlet kérése

A legfontosabb gépi ellenőrzés a linkkészlet:

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

Az RFC 9264 a application/linkset+json-t típusozott webhivatkozások halmazának önálló JSON-reprezentációjaként definiálja. A GS1 szigorítja a szerződést: a kimenetnek validálnia kell az 1.2.0-s verzió normatív linkkészlet-sémája ellen. Ezért ne csak azt ellenőrizze, hogy érkezik-e JSON, hanem a médiatípust, a sémát, az abszolút cél-URI-kat, az Anchor mezőt és a hivatkozásrelációkat is.

Különösen megtévesztők a formailag érvényes, szakmailag azonban hibás linkkészletek: például egy kézikönyv a termékinformációs oldal hivatkozástípusával, vagy sorozathoz kötött cél a GTIN-szinten. Ezért a séma validálását és a szakmai fixture-öket együtt kell alkalmazni.

4. A resolver leírásának ellenőrzése

Egy megfelelő resolver a /.well-known/gs1resolver alatt géppel olvasható leírást biztosít. Ez többek között megnevezi a resolver gyökerét és a támogatott elsődleges kulcsokat. A fájlnak validálnia kell a resolverleíró fájlokhoz készült GS1-séma ellen.

Ez a teszt egy gyakori ellentmondást előz meg: a szolgáltatás többre vagy kevesebbre képes, mint amit az önleírása állít. Ezért a jóváhagyásba a séma validálását és a valós tesztesetekkel való összevetést is vegye fel.

5. A CORS és a tartalom-egyeztetés tesztelése

A CORS nem kényelmi funkció. A szabvány azért írja elő, hogy a böngészőalapú alkalmazások domainközi módon elérhessék a resolvert. Teszteljen legalább egy engedélyezett böngésző-Origint és az előzetes kérést kezelő útvonalat. Ellenőrizze azt is, hogy a Accept: application/linkset+json és a linkType=linkset következetes eredményeket adnak-e.

Egészítse ki a tesztet egy nem támogatott médiatípusra vonatkozó negatív esettel. Az a szolgáltatás, amely a Accept-fejléctől függetlenül mindig HTML-t küld, emberek számára ugyan elérhető, de gépi feldolgozásra nem megbízható.

6. A nyelv, a kontextus és a részletesség lefedése

A szabvány a Accept-Language-t, valamint a context lekérdezési paramétert biztosítja az egymáshoz illeszkedő hivatkozások megkülönböztetésére. Nem minden resolvernek kell minden változatot kínálnia. Ha azonban támogatja a nyelvet vagy a kontextust, a kiválasztási szabályoknak reprodukálhatónak kell lenniük.

Teszteljen egy létező nyelvet, egy nem létező nyelvet és egy meghatározott tartalék-sorrendet. A GTIN, a tétel- és a sorozatszám esetében ugyanez az elv érvényes: a részletesebb azonosító figyelembe veheti a magasabb szintek releváns hivatkozásait anélkül, hogy elhomályosítaná a szakmai hozzárendelést. A várt hivatkozásmennyiséget fixture-ként rögzítse; a sorrendre épülő, tisztán snapshot-alapú tesztek túl törékenyek.

7. A hibák szemantikai megkülönböztetése

A hibakódok a szerződés részét képezik. A resolver szabványa a szintaktikailag érvénytelen GS1-azonosítókhoz HTTP 400-as választ ír elő. Ha egy konkrét, nem elérhető hivatkozástípust kérnek, az alapértelmezett célra való átirányítás éppen nem a helyes válasz. Ezeket az eseteket el kell különíteni az ismeretlen, de szintaktikailag érvényes azonosítótól.

Ellenőrizze azt is, hogy a hibaválaszok nem fednek-e fel belső részleteket, tokeneket vagy stack trace-eket, és hogy a GET, a HEAD és a böngészőalapú kérések ugyanazt a szemantikát őrzik-e. Egy tetszetős HTML-hibaoldal nem ellensúlyozhatja a hibás állapotkódot.

A GS1-tesztcsomag helyes használata

A nyilvános tesztcsomag egy Digital Link-URI-t fogad, és a viselkedést a Resolver 1.2.0-val veti össze. Független smoke- és megfelelőségi ellenőrzésként jól használható. A jóváhagyáshoz mentse el a teszt dátumát, a tesztelt URI-t, a szabvány verzióját, az eredményt és adott esetben a reprodukálható hibás eseteket.

A csomag azonban nem helyettesíti a saját regressziós teszteket. A GS1 kifejezetten jelzi, hogy jelenleg nem ellenőrzi a tömörítést. Ha a resolver EPC bináris karakterláncokat vagy további tömörített formákat dolgoz fel, ezekhez külön tesztvektorokra van szükség. A nyilvános csomag ugyanígy nem ismeri az Ön szakmai hivatkozástípusait, illetve engedélyezési, bérlői vagy elérhetőségi követelményeit.

Ezért egy megbízható folyamat három szintet kombinál:

a nyilvános GS1-csomag külső megfelelőségi ellenőrzésként;
a linkkészlet és a resolverleírás sématesztjei CI-ban;
saját végponttól végpontig tesztek valós azonosítókhoz, szerepkörökhöz, nyelvekhez és kiesésekhez.

Mi tartozzon a jóváhagyási bizonyítékok közé?

Az átvétel csak akkor ismételhető meg, ha az eredmény nemcsak a böngészőben látható, hanem dokumentált is. A jóváhagyási bizonyítéknak legalább a szabvány és a csomag verzióját, a teszt időpontját, a célkörnyezetet, a teszt-URI-kat, a várt hivatkozástípusokat, a HTTP-eredményeket, a séma validálását, a CORS-ellenőrzést és az ismert kivételeket kell tartalmaznia.

Automatizálja a stabil részeket CI-ban, de minden jelentős resolver-módosítás előtt végezzen célzott külső futtatást a nyilvános csomaggal. Így a „megnyílik a QR-kód” állításból ellenőrizhető kijelentés lesz az azonosítóról, az útválasztásról és a géppel olvasható termékinformációkról.