Testovací sada Resolveru GS1: DPP-odkazy důkladně ověřit před uvedením do provozu

QR kód, který v prohlížeči otevře stránku, ještě není důkazem spolehlivého Resolveru. U Resolveru GS1 pro digitální odkazy záleží na úplném chování HTTP: Které identifikátory jsou přijímány? Jaký cíl je výchozí? Poskytuje služba strojově čitelnou sadu odkazů? Fungují přístupy z prohlížeče přes jiné domény? A hlásí neplatné nebo nedostupné požadavky správnou chybu?

Od 16. ledna 2026 je k dispozici GS1-Conformant Resolver Standard 1.2.0. Příslušná veřejná testovací sada GS1 je nyní považována za stabilní; její kód byl naposledy aktualizován 29. června 2026. Z abstraktní normy tak lze vytvořit konkrétní akceptační test. Tento článek ukazuje, co je třeba ověřit před uvedením do provozu, kde má testovací sada své limity a jaké doklady patří do technického schválení.

Úspěšné skenování je teprve začátek

Jeden GS1 Digital Link obsahuje identifikátor GS1 v URI HTTPS. Resolver propojí tento identifikátor s jedním nebo více zdroji, například se stránkou produktu, návodem, datovým listem nebo programovým rozhraním. Náš úvodní článek vysvětluje Resolver GS1 pro digitální odkazy na živém příkladu. Pro schválení produkčního provozu však úspěšné standardní přesměrování nestačí.

Standard Resolveru 1.2.0 mimo jiné vyžaduje HTTPS, podporu pro GET, HEAD a OPTIONS, Cross-Origin Resource Sharing (CORS), rozpoznatelný výchozí odkaz a výstup ve formě sady odkazů. Při linkType=linkset nebo hlavičce Accept application/linkset+json nesmí Resolver přesměrovat. Místo toho musí vrátit dostupné typované odkazy jako samostatnou reprezentaci.

Toto rozlišení je důležité: Cesta pro lidského uživatele v prohlížeči může fungovat, zatímco strojový přístup, jazyk, typy odkazů nebo chybové stavy mohou být nefunkční. Právě takové odchylky zůstávají při pouhém testu skenování skryté.

Akceptační plán v sedmi krocích

1. Stanovte reprezentativní testovací URI

Nezačínejte jediným vzorovým produktem. Připravte malou verzovanou testovací sadu:

alespoň jeden platný identifikátor pro každý podporovaný primární klíč GS1;
jeden případ GTIN bez kvalifikátoru;
případy s šarží nebo sériovým číslem, pokud je tato granularita podporována;
syntakticky neplatný identifikátor;
platný, ale neznámý identifikátor;
známý identifikátor bez požadovaného typu odkazu.

Standard umožňuje Resolveru podporovat pouze podmnožinu primárních klíčů GS1. U každého podporovaného primárního klíče však musí být jeho kvalifikátory a datové atributy zpracovány úplně. Testovací sada proto musí odpovídat skutečně deklarovaným schopnostem, nikoli paušálnímu marketingovému tvrzení.

2. Ověřte standardní přesměrování a metody

Nejprve otestujte běžné volání bez zvláštních hlaviček. Očekává se deterministický výchozí odkaz. Poté následují HEAD a OPTIONS: HEAD nesmí používat jinou směrovací logiku než GET a OPTIONS musí srozumitelně zpřístupnit nabízené metody.

Minimální ruční test vypadá takto:

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

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

Zdokumentujte stavový kód, Location, hlavičky cache a počet přesměrování. Smyčka přesměrování, náhodný cíl nebo cesta odlišná podle metody jsou důvodem k neschválení, i když chytrý telefon nakonec zobrazí stránku.

3. Vyžádejte sadu odkazů místo webové stránky

Nejdůležitější strojovou kontrolou je sada odkazů:

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

RFC 9264 definuje application/linkset+json jako samostatnou reprezentaci JSON množiny typovaných webových odkazů. GS1 smluvní požadavky zpřísňuje: Výstup musí být validní podle normativního schématu sady odkazů pro verzi 1.2.0. Nekontrolujte proto pouze to, zda se vrací JSON, ale také typ média, schéma, absolutní cílová URI, kotvu a relace odkazů.

Obzvlášť zrádné jsou formálně platné, ale věcně nesprávné sady odkazů: například příručka pod typem odkazu pro produktovou informační stránku nebo cíl vztahující se k sérii na úrovni GTIN. Validace schématu a věcné přípravky proto patří k sobě.

4. Zkontrolujte popis Resolveru

Konformní Resolver poskytuje pod /.well-known/gs1resolver strojově čitelný popis. Uvádí mimo jiné kořen Resolveru a podporované primární klíče. Soubor musí být validní podle schématu GS1 pro soubory s popisem Resolveru.

Tento test odhalí častou nekonzistenci: Služba umí více nebo méně, než tvrdí její vlastní popis. Do akceptace proto zahrňte validaci schématu i porovnání s reálnými testovacími případy.

5. Otestujte CORS a vyjednávání obsahu

CORS není pouhá komfortní funkce. Standard jej vyžaduje, aby prohlížečové aplikace mohly Resolver oslovovat napříč doménami. Otestujte alespoň jeden povolený origin prohlížeče i cestu preflight. Ověřte také, zda Accept: application/linkset+json a linkType=linkset poskytují konzistentní výsledky.

Přidejte negativní test pro nepodporovaný typ média. Služba, která bez ohledu na hlavičku Accept vždy odesílá HTML, je sice dostupná lidem, ale není spolehlivě strojově čitelná.

6. Pokryjte jazyk, kontext a granularitu

Standard stanoví Accept-Language a parametr dotazu context jako prostředky k rozlišení mezi více vhodnými odkazy. Ne každý Resolver musí nabízet každou variantu. Pokud podporuje jazyk nebo kontext, pravidla výběru však musí být reprodukovatelná.

Otestujte proto dostupný jazyk, nedostupný jazyk a definované pořadí náhrad. Pro GTIN, šarži a sériové číslo platí stejný princip: Přesnější identifikátor může zohlednit relevantní odkazy vyšších úrovní, aniž by se setřelo věcné přiřazení. Očekávaný počet odkazů evidujte jako přípravek; čisté snapshotové testy pořadí jsou příliš křehké.

7. Rozlišujte chyby sémanticky

Chybové kódy jsou součástí smlouvy. Standard Resolveru pro syntakticky neplatné identifikátory GS1 stanoví odpověď s HTTP 400. Je-li vyžádán konkrétní nedostupný typ odkazu, přesměrování na výchozí cíl právě není správnou odpovědí. Tyto případy je třeba odlišit od neznámého, ale syntakticky platného identifikátoru.

Ověřte také, zda chybové odpovědi neprozrazují interní podrobnosti, tokeny nebo trasování zásobníku a zda si GET, HEAD a požadavky z prohlížeče zachovávají stejnou sémantiku. Hezký dokument HTML s chybou nedokáže napravit nesprávný stavový kód.

Jak správně používat testovací sadu GS1

Veřejná testovací sada přijímá URI digitálního odkazu a ověřuje chování proti Resolveru 1.2.0. Dobře se hodí jako nezávislá kontrola smoke testu a shody. Pro schválení uložte datum testu, testovanou URI, verzi standardu, výsledek a případně reprodukovatelné chybové případy.

Sada však nenahrazuje vlastní regresní testování. GS1 výslovně upozorňuje, že v současnosti nekontroluje kompresi. Pokud váš Resolver zpracovává binární řetězce EPC nebo další komprimované formy, potřebujete pro ně samostatné testovací vektory. Veřejná sada rovněž nezná vaše věcné typy odkazů ani požadavky na autorizaci, multitenantní provoz či dostupnost.

Spolehlivý proces proto kombinuje tři úrovně:

veřejnou sadu GS1 jako externí kontrolu shody;
testy schémat pro sadu odkazů a popis Resolveru v CI;
vlastní end-to-end testy reálných identifikátorů, rolí, jazyků a výpadků.

Co patří do dokladu o schválení

Akceptace je opakovatelná teprve tehdy, když výsledek není pouze viditelný v prohlížeči, ale je také zdokumentovaný. Doklad o schválení by měl obsahovat přinejmenším verzi standardu a sady, čas testu, cílové prostředí, testovací URI, očekávané typy odkazů, výsledky HTTP, validaci schématu, kontrolu CORS a známé výjimky.

Stabilní části automatizujte v CI, ale před každou významnou změnou Resolveru zachovejte cílený externí běh proti veřejné sadě. Z tvrzení „QR kód se otevře“ se tak stane ověřitelné tvrzení o identitě, směrování a strojově čitelných produktových informacích.