GS1 Resolver Test Suite: DPP-Links vor dem Go-live belastbar prüfen

Ein QR-Code, der im Browser eine Seite öffnet, beweist noch keinen belastbaren Resolver. Für einen GS1-Digital-Link-Resolver zählt das vollständige HTTP-Verhalten: Welche Identifier werden akzeptiert? Welches Ziel ist der Standard? Liefert der Dienst ein maschinenlesbares Linkset? Funktionieren Browserzugriffe über andere Domains? Und melden ungültige oder nicht verfügbare Anfragen den richtigen Fehler?

Seit dem 16. Januar 2026 liegt der GS1-Conformant Resolver Standard 1.2.0 vor. Die dazugehörige öffentliche GS1-Test-Suite gilt inzwischen als stabil; ihr Code wurde zuletzt am 29. Juni 2026 aktualisiert. Damit lässt sich aus einer abstrakten Norm ein konkreter Abnahmetest machen. Dieser Beitrag zeigt, was vor dem Go-live geprüft werden sollte, wo die Test-Suite Grenzen hat und welche Nachweise in eine technische Freigabe gehören.

Ein erfolgreicher Scan ist nur der Anfang

Ein GS1 Digital Link trägt einen GS1-Identifier in einer HTTPS-URI. Der Resolver verbindet diesen Identifier mit einem oder mehreren Ressourcen, etwa einer Produktseite, einer Anleitung, einem Datenblatt oder einer Programmierschnittstelle. Unser Grundlagenbeitrag erklärt den GS1-Digital-Link-Resolver mit einem Live-Beispiel. Für eine Produktionsfreigabe reicht ein erfolgreicher Standard-Redirect jedoch nicht.

Der Resolver-Standard 1.2.0 verlangt unter anderem HTTPS, Unterstützung für GET, HEAD und OPTIONS, Cross-Origin Resource Sharing (CORS), einen erkennbaren Standard-Link sowie eine Linkset-Ausgabe. Bei linkType=linkset oder dem Accept-Header application/linkset+json darf der Resolver nicht umleiten. Er muss stattdessen die verfügbaren typisierten Links als eigenständige Repräsentation zurückgeben.

Diese Trennung ist wichtig: Der menschliche Browserpfad kann funktionieren, während Maschinenzugriff, Sprache, Linktypen oder Fehlerfälle defekt sind. Genau solche Abweichungen bleiben bei einem reinen Scan-Test unsichtbar.

Der Abnahmeplan in sieben Schritten

1. Repräsentative Test-URIs festlegen

Beginnen Sie nicht mit einem einzigen Musterprodukt. Stellen Sie eine kleine, versionierte Testsammlung zusammen:

mindestens einen gültigen Identifier pro unterstütztem GS1-Primärschlüssel;
einen GTIN-Fall ohne Qualifier;
Fälle mit Charge oder Seriennummer, sofern diese Granularität unterstützt wird;
einen syntaktisch ungültigen Identifier;
einen gültigen, aber nicht bekannten Identifier;
einen bekannten Identifier ohne den angefragten Linktyp.

Der Standard erlaubt einem Resolver, nur eine Teilmenge der GS1-Primärschlüssel zu unterstützen. Für jeden unterstützten Primärschlüssel müssen aber dessen Qualifier und Datenattribute vollständig verarbeitet werden. Darum muss die Testmenge zur tatsächlich erklärten Fähigkeit passen, nicht zu einer pauschalen Marketingaussage.

2. Standard-Redirect und Methoden prüfen

Testen Sie den normalen Aufruf zuerst ohne besondere Header. Erwartet wird ein deterministischer Standard-Link. Danach folgen HEAD und OPTIONS: HEAD darf keine andere Routinglogik verwenden als GET, und OPTIONS muss die angebotenen Methoden nachvollziehbar machen.

Ein minimaler manueller Test sieht so aus:

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

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

Dokumentieren Sie Statuscode, Location, Cache-Header und die Anzahl der Redirects. Eine Redirect-Schleife, ein zufälliges Ziel oder ein je Methode abweichender Pfad ist ein Freigabefehler, auch wenn ein Smartphone irgendwann eine Seite zeigt.

3. Linkset statt Webseite anfordern

Die wichtigste Maschinenprüfung ist das Linkset:

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

RFC 9264 definiert application/linkset+json als eigenständige JSON-Repräsentation einer Menge typisierter Weblinks. GS1 verschärft den Vertrag: Die Ausgabe muss gegen das normative Linkset-Schema für Version 1.2.0 validieren. Prüfen Sie deshalb nicht nur, ob JSON zurückkommt, sondern auch Medientyp, Schema, absolute Ziel-URIs, Anchor und Linkrelationen.

Besonders tückisch sind formal gültige, fachlich aber falsche Linksets: etwa ein Handbuch unter dem Linktyp für eine Produktinformationsseite oder ein serienbezogenes Ziel am GTIN-Level. Schema-Validierung und fachliche Fixtures gehören deshalb zusammen.

4. Resolver-Beschreibung kontrollieren

Ein konformer Resolver stellt unter /.well-known/gs1resolver eine maschinenlesbare Beschreibung bereit. Sie nennt unter anderem den Resolver-Stamm und die unterstützten Primärschlüssel. Die Datei muss gegen das GS1-Schema für Resolver Description Files validieren.

Dieser Test verhindert eine häufige Inkonsistenz: Der Dienst kann mehr oder weniger als seine Selbstauskunft behauptet. Nehmen Sie deshalb sowohl Schema-Validierung als auch einen Abgleich mit realen Testfällen in die Abnahme auf.

5. CORS und Content Negotiation testen

CORS ist kein Komfortmerkmal. Der Standard verlangt es, damit browserbasierte Anwendungen den Resolver domainübergreifend ansprechen können. Testen Sie mindestens einen erlaubten Browser-Origin sowie den Preflight-Pfad. Prüfen Sie außerdem, ob Accept: application/linkset+json und linkType=linkset konsistente Resultate liefern.

Ergänzen Sie einen Negativtest für einen nicht unterstützten Medientyp. Ein Dienst, der unabhängig vom Accept-Header immer HTML sendet, ist zwar für Menschen erreichbar, aber nicht verlässlich maschinenlesbar.

6. Sprache, Kontext und Granularität abdecken

Der Standard sieht Accept-Language sowie den Query-Parameter context als Mittel vor, um zwischen mehreren passenden Links zu unterscheiden. Nicht jeder Resolver muss jede Variante anbieten. Wenn Sprache oder Kontext unterstützt werden, müssen die Auswahlregeln aber reproduzierbar sein.

Testen Sie deshalb eine vorhandene Sprache, eine nicht vorhandene Sprache und eine definierte Fallback-Reihenfolge. Für GTIN, Charge und Seriennummer gilt dasselbe Prinzip: Ein feiner Identifier darf relevante Links höherer Ebenen berücksichtigen, ohne die fachliche Zuordnung zu verwischen. Halten Sie die erwartete Linkmenge als Fixture fest; reine Snapshot-Tests auf die Reihenfolge sind zu fragil.

7. Fehler semantisch unterscheiden

Fehlercodes sind Teil des Vertrags. Der Resolver-Standard sieht für syntaktisch ungültige GS1-Identifier eine Meldung mit HTTP 400 vor. Wird ein konkreter, nicht verfügbarer Linktyp angefragt, ist ein Redirect auf das Standardziel gerade nicht die richtige Antwort. Solche Fälle müssen getrennt werden von einem unbekannten, aber syntaktisch gültigen Identifier.

Prüfen Sie auch, ob Fehlerantworten keine internen Details, Tokens oder Stacktraces preisgeben und ob GET, HEAD und browserbasierte Anfragen dieselbe Semantik behalten. Ein hübsches HTML-Fehlerdokument kann einen falschen Statuscode nicht ausgleichen.

Die GS1-Test-Suite richtig einsetzen

Die öffentliche Test-Suite nimmt eine Digital-Link-URI entgegen und prüft das Verhalten gegen Resolver 1.2.0. Sie eignet sich gut als unabhängiger Smoke- und Konformitätscheck. Speichern Sie zur Freigabe das Testdatum, die getestete URI, die Standardversion, das Ergebnis und gegebenenfalls reproduzierbare Fehlerfälle.

Die Suite ersetzt jedoch keine eigene Regression. GS1 weist ausdrücklich darauf hin, dass sie Kompression derzeit nicht prüft. Wenn Ihr Resolver EPC-Binärstrings oder weitere komprimierte Formen verarbeitet, benötigen Sie dafür separate Testvektoren. Ebenso kennt die öffentliche Suite weder Ihre fachlichen Linktypen noch Ihre Autorisierungs-, Mandanten- oder Verfügbarkeitsanforderungen.

Ein belastbarer Prozess kombiniert daher drei Ebenen:

die öffentliche GS1-Suite als externer Konformitätscheck;
Schema-Tests für Linkset und Resolver-Beschreibung in CI;
eigene End-to-End-Tests für reale Identifier, Rollen, Sprachen und Ausfälle.

Was in den Freigabenachweis gehört

Eine Abnahme ist erst wiederholbar, wenn das Ergebnis nicht nur im Browser sichtbar, sondern dokumentiert ist. Der Freigabenachweis sollte mindestens Standard- und Suite-Version, Testzeitpunkt, Zielumgebung, Test-URIs, erwartete Linktypen, HTTP-Ergebnisse, Schema-Validierung, CORS-Prüfung und bekannte Ausnahmen enthalten.

Automatisieren Sie die stabilen Teile in CI, aber lassen Sie einen gezielten externen Lauf gegen die öffentliche Suite vor jeder wesentlichen Resolver-Änderung bestehen. So wird aus „der QR-Code öffnet sich“ eine überprüfbare Aussage über Identität, Routing und maschinenlesbare Produktinformationen.