GS1 Resolver Test Suite: DPP-länkar före produktionssättning tillförlitligt verifierade

En QR-kod som öppnar en sida i webbläsaren bevisar ännu inte att en resolver är tillförlitlig. För en resolver som hanterar GS1-länkar är hela HTTP-beteendet avgörande: Vilka identifierare accepteras? Vilket mål är standard? Levererar tjänsten ett maskinläsbart länkset? Fungerar webbläsaråtkomst från andra domäner? Och rapporterar ogiltiga eller otillgängliga förfrågningar rätt fel?

Sedan 16 januari 2026 finns GS1-Conformant Resolver Standard 1.2.0. Den tillhörande offentliga GS1-testsviten betraktas nu som stabil; koden uppdaterades senast 29 juni 2026. Därmed kan en abstrakt standard omvandlas till ett konkret godkännandetest. Den här artikeln visar vad som bör kontrolleras före produktionssättning, var testsviten har sina begränsningar och vilka bevis som bör ingå i ett tekniskt godkännande.

En lyckad skanning är bara början

En GS1 Digital Link innehåller en GS1-identifierare i en HTTPS-URI. Resolvern kopplar identifieraren till en eller flera resurser, exempelvis en produktsida, en bruksanvisning, ett datablad eller ett programmeringsgränssnitt. Vår grundläggande artikel förklarar resolvern för GS1-länkar med ett liveexempel. För ett produktionsgodkännande räcker en lyckad standardomdirigering ändå inte.

Resolver-standarden 1.2.0 kräver bland annat HTTPS, stöd för GET, HEAD och OPTIONS, Cross-Origin Resource Sharing (CORS), en identifierbar standardlänk samt ett länkset. Vid linkType=linkset eller Accept-huvudet application/linkset+json får resolvern inte omdirigera. Den ska i stället returnera de tillgängliga typbestämda länkarna som en fristående representation.

Denna åtskillnad är viktig: Den mänskliga webbläsarvägen kan fungera, medan maskinåtkomst, språk, länktyper eller felsituationer är trasiga. Just sådana avvikelser förblir osynliga vid ett rent skanningstest.

Godkännandeplanen i sju steg

1. Fastställ representativa test-URI:er

Börja inte med en enda modellprodukt. Sätt samman en liten, versionshanterad testsamling:

minst en giltig identifierare per GS1-primärnyckel som stöds;
ett GTIN-fall utan kvalificerare;
fall med batch- eller serienummer, om denna granularitet stöds;
en syntaktiskt ogiltig identifierare;
en giltig men okänd identifierare;
en känd identifierare utan den efterfrågade länktypen.

Standarden tillåter att en resolver endast stöder en delmängd av GS1:s primärnycklar. För varje primärnyckel som stöds måste dock dess kvalificerare och dataattribut hanteras fullständigt. Därför måste testmängden motsvara den faktiska deklarerade förmågan, inte ett generellt marknadsföringspåstående.

2. Kontrollera standardomdirigering och metoder

Testa det normala anropet först utan särskilda huvuden. En deterministisk standardlänk förväntas. Därefter följer HEAD och OPTIONS: HEAD får inte använda någon annan routningslogik än GET, och OPTIONS måste göra de erbjudna metoderna begripliga.

Ett minimalt manuellt test ser ut så här:

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

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

Dokumentera statuskod, Location, cachehuvuden och antalet omdirigeringar. En omdirigeringsslinga, ett slumpmässigt mål eller en väg som avviker per metod är ett godkännandefel, även om en smartphone till slut visar en sida.

3. Begär ett länkset i stället för en webbsida

Den viktigaste maskinkontrollen är länksetet:

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

RFC 9264 definierar application/linkset+json som en fristående JSON-representation av en mängd typbestämda webblänkar. GS1 skärper avtalet: Utdata måste validera mot det normativa länksetschemat för version 1.2.0. Kontrollera därför inte bara att JSON returneras, utan även medietyp, schema, absoluta mål-URI:er, Anchor och länkrelationer.

Särskilt förrädiska är formellt giltiga men sakligt felaktiga länkset: exempelvis en handbok under länktypen för en produktinformationssida eller ett serienummerrelaterat mål på GTIN-nivå. Schemavalidering och sakliga testdata hör därför ihop.

4. Kontrollera resolverbeskrivningen

En kompatibel resolver tillhandahåller en maskinläsbar beskrivning under /.well-known/gs1resolver. Den anger bland annat resolverns rot och de primärnycklar som stöds. Filen måste validera mot GS1-schemat för resolverbeskrivningsfiler.

Detta test förhindrar en vanlig inkonsekvens: Tjänsten kan mer eller mindre än vad dess självbeskrivning hävdar. Ta därför med både schemavalidering och en jämförelse med verkliga testfall i godkännandet.

5. Testa CORS och innehållsförhandling

CORS är ingen bekvämlighetsfunktion. Standarden kräver det så att webbläsarbaserade applikationer kan anropa resolver över domängränser. Testa minst en tillåten webbläsar-Origin samt preflight-vägen. Kontrollera dessutom om Accept: application/linkset+json och linkType=linkset ger konsekventa resultat.

Lägg till ett negativt test för en medietyp som inte stöds. En tjänst som alltid skickar HTML oberoende av Accept-huvudet är visserligen åtkomlig för människor, men inte tillförlitligt maskinläsbar.

6. Täcka språk, kontext och granularitet

Standarden anger Accept-Language samt frågeparametern context som metoder för att skilja mellan flera matchande länkar. Alla resolvrar behöver inte erbjuda varje variant. Om språk eller kontext stöds måste urvalsreglerna dock vara reproducerbara.

Testa därför ett befintligt språk, ett språk som saknas och en definierad reservordning. För GTIN, batch och serienummer gäller samma princip: En mer detaljerad identifierare får ta hänsyn till relevanta länkar på högre nivåer utan att den sakliga kopplingen blir otydlig. Dokumentera den förväntade länk mängden som testdata; rena snapshot-tester av ordningen är för bräckliga.

7. Skilj semantiskt mellan fel

Felkoder är en del av avtalet. Resolverstandarden anger ett svar med HTTP 400 för syntaktiskt ogiltiga GS1-identifierare. När en specifik, otillgänglig länktyp efterfrågas är en omdirigering till standardmålet inte rätt svar. Sådana fall måste skiljas från en okänd men syntaktiskt giltig identifierare.

Kontrollera också att felsvar inte avslöjar interna detaljer, token eller stacktraces och att GET, HEAD och webbläsarbaserade anrop behåller samma semantik. Ett snyggt HTML-feldokument kan inte kompensera för en felaktig statuskod.

Använda GS1-testsviten på rätt sätt

Den offentliga testsviten tar emot en URI för digitala länkar och kontrollerar beteendet mot Resolver 1.2.0. Den lämpar sig väl som en oberoende smoke- och överensstämmelsekontroll. Spara testdatum, testad URI, standardversion, resultat och vid behov reproducerbara felsituationer som del av godkännandet.

Sviten ersätter dock inte egen regressionstestning. GS1 påpekar uttryckligen att komprimering för närvarande inte testas. Om din resolver hanterar EPC-binärsträngar eller andra komprimerade former behöver du separata testvektorer för detta. Den offentliga sviten känner inte heller till dina sakliga länktyper eller dina krav på auktorisering, flera klienter eller tillgänglighet.

En robust process kombinerar därför tre nivåer:

den offentliga GS1-sviten som extern överensstämmelsekontroll;
schematester för länkset och resolverbeskrivning i CI;
egna end-to-end-tester för verkliga identifierare, roller, språk och avbrott.

Vad som ska ingå i godkännandeunderlaget

Ett godkännande är reproducerbart först när resultatet inte bara syns i webbläsaren utan också är dokumenterat. Underlaget bör minst innehålla standard- och svitversion, testtidpunkt, målmiljö, test-URI:er, förväntade länktyper, HTTP-resultat, schemavalidering, CORS-kontroll och kända undantag.

Automatisera de stabila delarna i CI, men genomför en riktad extern körning mot den offentliga sviten före varje större resolverändring. Då blir ”QR-koden öppnas” ett verifierbart påstående om identitet, routning och maskinläsbar produktinformation.