Naar inhoud
Product ID
Terug naar de hoofdpagina
Technische verdieping

Hoe beslist de resolver
wat hij teruggeeft?

Achter elke scan gaat een slim gesprek schuil tussen de app en de resolver. Op deze pagina leggen we precies uit hoe dat werkt — voor iedereen die de techniek echt wil begrijpen.

Wanneer een QR-code gescand wordt, stuurt de app een gewoon HTTP-verzoek naar de resolver — hetzelfde protocol als wanneer je een website bezoekt. Maar in dat verzoek zit veel meer informatie dan alleen "geef me die pagina". De resolver leest die informatie en geeft op basis daarvan een op maat gesneden antwoord.

De resolver gebruikt onder meer het linktype, voorkeuren in HTTP-headers zoals taal, eventuele context, en de linkset die de merkhouder heeft ingesteld.

Stap 1

De app vraagt een specifiek link type op

Elke soort informatie heeft een eigen link type — een gestandaardiseerde naam die aangeeft wát er gevraagd wordt. Die namen zijn vastgelegd door GS1 zodat elke app wereldwijd hetzelfde spreekt. Voorbeelden:

gs1:pip → productpagina van het merk
gs1:allergenInfo → allergenenlijst
gs1:nutritionalInfo → voedingswaarden
gs1:sustainabilityInfo → duurzaamheidsdata
gs1:recipeInfo → recepten
gs1:traceability → herkomst & tracering

Het link type wordt als query parameter aan de URL meegegeven. Een allergieker-app stuurt bijvoorbeeld:

GET https://id.productid.nl/01/08710123456784?linkType=gs1:allergenInfo

Een gewone consumentencamera stuurt meestal géén link type mee. De resolver stuurt dan met een HTTP 307 Temporary Redirect door naar de geregistreerde standaardlink. Die link kan tegelijk als bijvoorbeeld gs1:pip zijn beschreven, maar dat hoeft niet.

Stap 2

De resolver raadpleegt de link set van de merkhouder

De merkhouder heeft in de resolver een link set geregistreerd: een gestructureerde lijst van alle beschikbare link types voor dat product, elk gekoppeld aan een URL. De resolver vergelijkt het gevraagde link type met wat er beschikbaar is en stuurt door.

Een linkset kan conform de actuele GS1 Resolver Standard zo als JSON worden weergegeven:

{
  "linkset": [{
    "anchor": "https://id.productid.nl/01/08710123456789",
    "description": "Biologische olijfolie extra vierge 500ml",
    "https://ref.gs1.org/voc/pip": [{
        "href": "https://merk.nl/olijfolie",
        "title": "Productpagina olijfolie",
        "hreflang": ["nl"]
      }],
    "https://ref.gs1.org/voc/allergenInfo": [{
        "href": "https://data.merk.nl/allergenen/olijfolie",
        "title": "Allergeneninformatie olijfolie",
        "type": "application/json"
      }],
    "https://ref.gs1.org/voc/nutritionalInfo": [{
        "href": "https://data.merk.nl/voeding/olijfolie",
        "title": "Voedingswaarden olijfolie",
        "type": "application/json"
      }],
    "https://ref.gs1.org/voc/sustainabilityInfo": [{
        "href": "https://merk.nl/duurzaamheid",
        "title": "Duurzaamheid en recycling"
      }]
  }]
}

Naast een doorverwijzing naar één specifieke URL kan de resolver ook de volledige linkset teruggeven. Dat gebeurt bij ?linkType=linkset of met de HTTP Accept-header application/linkset+json:

GET https://id.productid.nl/01/08710123456789?linkType=linkset

De resolver antwoordt dan met de volledige link set als JSON, met HTTP-status 200 OK — geen redirect. Zo kan een retailersysteem of logistieke scanner zelfstandig kiezen welke data het ophaalt, zonder afhankelijk te zijn van de ingestelde standaard.

Stap 3

Taal helpt de juiste versie bepalen

Een HTTP-verzoek kan een Accept-Language-header bevatten, doorgaans gebaseerd op de taalinstelling van de gebruiker. Een resolver hoort deze voorkeur te ondersteunen en kan daarmee de meest passende variant kiezen.

HTTP Request headers
Accept-Language: nl-NL, nl;q=0.9, en;q=0.8

In de link set kan de merkhouder per link type meerdere taalvarianten registreren:

"https://ref.gs1.org/voc/pip": [
  { "href": "https://merk.nl/olijfolie", "title": "Olijfolie", "hreflang": ["nl"] },
  { "href": "https://merk.com/oliveoil", "title": "Olive oil", "hreflang": ["en"] },
  { "href": "https://merk.de/olivenoel", "title": "Olivenöl", "hreflang": ["de"] }
]

De resolver volgt hierbij de prioriteitsvolgorde uit de Accept-Language-header. Een gebruiker met nl-NL als primaire taal wordt doorgestuurd naar de Nederlandse variant. Staat alleen nl geregistreerd (zonder regio), dan accepteert de resolver ook nl-BE of nl-NL als match.

Zonder expliciet linktype leidt een ontbrekende taalmatch doorgaans tot de standaardlink. Is wel een specifiek linktype gevraagd en zijn daarvoor meerdere taalvarianten beschikbaar zonder passende match, dan kan de resolver antwoorden met 300 Multiple Choices en de beschikbare links tonen.

Speciale situatie

THT en batchnummer direct in de URL

Naast het GTIN kan de GS1 Digital Link ook de houdbaarheidsdatum (THT) en het batchnummer in de URL coderen. Het batchnummer staat als kwalificatie in het pad; AI (15) voor de THT staat als data-attribuut in de querystring. AI (17) wordt gebruikt voor een verval- of uiterste gebruiksdatum. Een scanner kan deze waarden lokaal uit de QR-code lezen, maar voor resolverlinks of actuele recallinformatie is een netwerkverbinding of andere databron nodig.

De structuur van zo'n volledige URL:

https://id.productid.nl/01/08710123456789/10/BATCH42?15=261231
/01/
GTIN — productidentificatie
/10/
Batchnummer / lotnummer
?15=
THT als queryparameter in JJMMDD (261231 = 31 dec 2026)

Een geschikt kassasysteem hoeft geen externe API te raadplegen om de gecodeerde datum zelf te lezen. Het kassasysteem kan op basis hiervan bijvoorbeeld lokale logica toepassen:

  • Automatisch korting activeren als de THT binnen drie dagen valt
  • Een artikel markeren voor controle wanneer de THT verstreken is
  • Alarm slaan bij een specifiek batchnummer dat in recall is

Het batchnummer maakt gerichte recalls mogelijk wanneer een fabrikant of andere bevoegde partij actuele recallinformatie voor die batch registreert. Een resolver kan vervolgens bijvoorbeeld via gs1:recallStatus naar die informatie verwijzen; het batchnummer alleen veroorzaakt niet automatisch een waarschuwing.

De volledige beslissingsstroom

1
App stuurt HTTP GET-verzoek
URL bevat GTIN (+ optioneel THT/batch). Headers bevatten Accept-Language en optioneel ?linkType=
2
Resolver ontleedt de URL
Extraheert GTIN en batchnummer uit het pad en de THT uit de querystring. Zoekt de bijbehorende linkset op.
3
Resolver kiest het juiste link type
Is er een ?linkType= parameter? → gebruik dat type. Geen parameter? → gebruik de geregistreerde standaardlink. ?linkType=linkset? → stuur de volledige linkset terug.
4
Resolver past taalfilter toe
Vergelijkt Accept-Language met de geregistreerde taalvarianten. Kiest een beste match of geeft meerdere keuzes wanneer geen unieke passende link kan worden bepaald.
5
Resolver antwoordt
Bij een enkele link: 307 Temporary Redirect naar de doel-URL. Bij ?linkType=linkset: 200 OK met de linkset. De app volgt de redirect of verwerkt het antwoord.

Wil je meer weten over wat dit betekent voor consumenten of leveranciers?

Terug naar de hoofdpagina