GS1 Resolver Test Suite: DPP-links vóór de livegang betrouwbaar testen

Een QR-code die in de browser een pagina opent, bewijst nog niet dat een resolver betrouwbaar werkt. Voor een GS1-Digital-Link-resolver telt het volledige HTTP-gedrag: welke identifiers worden geaccepteerd? Wat is het standaarddoel? Levert de dienst een machineleesbare linkset? Werken browseraanvragen vanaf andere domeinen? En geven ongeldige of niet-beschikbare aanvragen de juiste foutmelding?

Sinds 16 januari 2026 is de GS1-Conformant Resolver Standard 1.2.0 beschikbaar. De bijbehorende openbare GS1-testsuite geldt inmiddels als stabiel; de code is voor het laatst bijgewerkt op 29 juni 2026. Daarmee kan een abstracte norm worden omgezet in een concrete acceptatietest. Dit artikel laat zien wat vóór de livegang moet worden gecontroleerd, waar de testsuite grenzen heeft en welke bewijzen in een technische vrijgave thuishoren.

Een geslaagde scan is slechts het begin

Een GS1 Digital Link bevat een GS1-identifier in een HTTPS-URI. De resolver koppelt deze identifier aan een of meer bronnen, zoals een productpagina, handleiding, gegevensblad of programmeerinterface. Ons basisartikel legt de GS1-Digital-Link-resolver uit aan de hand van een livevoorbeeld. Voor een productievrijgave is een geslaagde standaardredirect echter niet voldoende.

De resolverstandaard 1.2.0 vereist onder meer HTTPS, ondersteuning voor GET, HEAD en OPTIONS, Cross-Origin Resource Sharing (CORS), een herkenbare standaardlink en een linksetuitvoer. Bij linkType=linkset of de Accept-header application/linkset+json mag de resolver niet doorverwijzen. In plaats daarvan moet hij de beschikbare getypeerde links als zelfstandige representatie teruggeven.

Dit onderscheid is belangrijk: het menselijke browserpad kan werken terwijl machineaanvragen, taal, linktypen of foutgevallen defect zijn. Juist zulke afwijkingen blijven bij een pure scantest onzichtbaar.

Het acceptatieplan in zeven stappen

1. Representatieve test-URI's vastleggen

Begin niet met één enkel modelproduct. Stel een kleine, versiebeheerste testverzameling samen:

ten minste één geldige identifier per ondersteunde GS1-primaire sleutel;
een GTIN-geval zonder qualifier;
gevallen met batch- of serienummer, voor zover deze granulariteit wordt ondersteund;
een syntactisch ongeldige identifier;
een geldige maar onbekende identifier;
een bekende identifier zonder het opgevraagde linktype.

De standaard staat een resolver toe om slechts een subset van de GS1-primaire sleutels te ondersteunen. Voor elke ondersteunde primaire sleutel moeten de qualifiers en gegevensattributen echter volledig worden verwerkt. Daarom moet de testset aansluiten bij de daadwerkelijk verklaarde mogelijkheden, niet bij een algemene marketingclaim.

2. Standaardredirect en methoden controleren

Test de normale aanroep eerst zonder bijzondere headers. Verwacht wordt een deterministische standaardlink. Daarna volgen HEAD en OPTIONS: HEAD mag geen andere routeringslogica gebruiken dan GET, en OPTIONS moet de aangeboden methoden inzichtelijk maken.

Een minimale handmatige test ziet er zo uit:

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

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

Documenteer statuscode, Location, cacheheaders en het aantal redirects. Een redirectlus, een willekeurig doel of een per methode afwijkend pad is een vrijgavefout, ook als een smartphone uiteindelijk een pagina toont.

3. Een linkset opvragen in plaats van een webpagina

De belangrijkste machinecontrole is de linkset:

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

RFC 9264 definieert application/linkset+json als een zelfstandige JSON-representatie van een verzameling getypeerde weblinks. GS1 maakt het contract strenger: de uitvoer moet valideren tegen het normatieve linksetschema voor versie 1.2.0. Controleer daarom niet alleen of er JSON wordt teruggestuurd, maar ook mediatype, schema, absolute doel-URI's, anchor en linkrelaties.

Bijzonder verraderlijk zijn formeel geldige maar inhoudelijk verkeerde linksets: bijvoorbeeld een handleiding onder het linktype voor een productinformatiewebsite of een serienummergebonden doel op GTIN-niveau. Schemavalidatie en inhoudelijke fixtures horen daarom bij elkaar.

4. De resolverbeschrijving controleren

Een conforme resolver stelt onder /.well-known/gs1resolver een machineleesbare beschrijving beschikbaar. Daarin staan onder meer de resolverbasis en de ondersteunde primaire sleutels. Het bestand moet valideren tegen het GS1-schema voor resolverbeschrijvingsbestanden.

Deze test voorkomt een veelvoorkomende inconsistentie: de dienst kan meer of minder dan zijn eigen beschrijving beweert. Neem daarom zowel schemavalidatie als een vergelijking met echte testgevallen op in de acceptatie.

5. CORS en content negotiation testen

CORS is geen gemaksfunctie. De standaard vereist dit zodat browsergebaseerde toepassingen de resolver domeinoverstijgend kunnen aanspreken. Test ten minste één toegestane browserorigin en het preflightpad. Controleer bovendien of Accept: application/linkset+json en linkType=linkset consistente resultaten opleveren.

Voeg een negatieve test toe voor een niet-ondersteund mediatype. Een dienst die ongeacht de Accept-header altijd HTML verstuurt, is wel voor mensen bereikbaar maar niet betrouwbaar machineleesbaar.

6. Taal, context en granulariteit afdekken

De standaard beschouwt Accept-Language en de queryparameter context als middelen om onderscheid te maken tussen meerdere passende links. Niet elke resolver hoeft elke variant aan te bieden. Als taal of context wordt ondersteund, moeten de selectieregels echter reproduceerbaar zijn.

Test daarom een beschikbare taal, een niet-beschikbare taal en een vastgelegde fallbackvolgorde. Voor GTIN, batch en serienummer geldt hetzelfde principe: een fijnmazige identifier mag relevante links van hogere niveaus meenemen zonder de inhoudelijke toewijzing te vertroebelen. Leg de verwachte linkverzameling vast als fixture; pure snapshottests op de volgorde zijn te fragiel.

7. Fouten semantisch onderscheiden

Foutcodes maken deel uit van het contract. De resolverstandaard schrijft voor syntactisch ongeldige GS1-identifiers een melding met HTTP 400 voor. Wanneer een concreet, niet-beschikbaar linktype wordt opgevraagd, is een redirect naar het standaarddoel juist niet het juiste antwoord. Zulke gevallen moeten worden onderscheiden van een onbekende maar syntactisch geldige identifier.

Controleer ook of foutantwoorden geen interne details, tokens of stacktraces prijsgeven en of GET, HEAD en browsergebaseerde aanvragen dezelfde semantiek behouden. Een fraai HTML-foutdocument kan een verkeerde statuscode niet compenseren.

De GS1-testsuite correct inzetten

De openbare testsuite neemt een Digital-Link-URI in ontvangst en controleert het gedrag tegen Resolver 1.2.0. Ze is geschikt als onafhankelijke smoke- en conformiteitscontrole. Bewaar voor de vrijgave de testdatum, de geteste URI, de standaardversie, het resultaat en waar nodig reproduceerbare foutgevallen.

De suite vervangt echter geen eigen regressietests. GS1 vermeldt uitdrukkelijk dat compressie momenteel niet wordt gecontroleerd. Als uw resolver EPC-binaire strings of andere gecomprimeerde vormen verwerkt, hebt u daarvoor afzonderlijke testvectoren nodig. De openbare suite kent evenmin uw inhoudelijke linktypen of uw vereisten voor autorisatie, tenants of beschikbaarheid.

Een betrouwbaar proces combineert daarom drie niveaus:

de openbare GS1-suite als externe conformiteitscontrole;
schematests voor linkset en resolverbeschrijving in CI;
eigen end-to-endtests voor echte identifiers, rollen, talen en storingen.

Wat in het vrijgavebewijs hoort

Een acceptatie is pas herhaalbaar wanneer het resultaat niet alleen in de browser zichtbaar maar ook gedocumenteerd is. Het vrijgavebewijs moet ten minste de standaard- en suiteversie, het testtijdstip, de doelomgeving, test-URI's, verwachte linktypen, HTTP-resultaten, schemavalidatie, CORS-controle en bekende uitzonderingen bevatten.

Automatiseer de stabiele onderdelen in CI, maar laat vóór elke ingrijpende resolverwijziging een gerichte externe run tegen de openbare suite uitvoeren. Zo wordt „de QR-code opent” een controleerbare uitspraak over identiteit, routering en machineleesbare productinformatie.