Pakiet testów Resolvera GS1: DPP-Linki — rzetelna weryfikacja przed uruchomieniem produkcyjnym

Kod QR, który otwiera stronę w przeglądarce, nie dowodzi jeszcze niezawodności Resolvera. W przypadku Resolvera GS1 dla tego standardu liczy się pełne zachowanie HTTP: Które identyfikatory są akceptowane? Jaki cel jest domyślny? Czy usługa dostarcza czytelny maszynowo zestaw linków? Czy dostęp z przeglądarki z innych domen działa? Czy nieprawidłowe lub niedostępne żądania zgłaszają właściwy błąd?

Od 16 stycznia 2026 r. dostępny jest GS1-Conformant Resolver Standard 1.2.0. Powiązany z nim publiczny pakiet testów GS1 jest obecnie uznawany za stabilny; jego kod zaktualizowano ostatnio 29 czerwca 2026 r. Dzięki temu abstrakcyjną normę można przekształcić w konkretny test odbiorczy. W tym artykule pokazano, co należy sprawdzić przed uruchomieniem produkcyjnym, jakie ograniczenia ma pakiet testów i jakie dowody powinny znaleźć się w technicznej akceptacji.

Udane skanowanie to dopiero początek

Jeden GS1 Digital Link zawiera identyfikator GS1 w identyfikatorze URI HTTPS. Resolver łączy ten identyfikator z jednym lub wieloma zasobami, na przykład stroną produktu, instrukcją, kartą danych lub interfejsem programistycznym. Nasz artykuł podstawowy wyjaśnia działanie Resolvera GS1 dla tego rozwiązania na żywym przykładzie. Do uruchomienia produkcyjnego nie wystarczy jednak udane standardowe przekierowanie.

Standard Resolvera 1.2.0 wymaga między innymi protokołu HTTPS, obsługi GET, HEAD i OPTIONS, mechanizmu Cross-Origin Resource Sharing (CORS), rozpoznawalnego linku domyślnego oraz wyjścia w postaci zestawu linków. W przypadku linkType=linkset lub nagłówka Accept application/linkset+json Resolver nie może przekierowywać. Zamiast tego musi zwrócić dostępne linki typowane jako samodzielną reprezentację.

To rozdzielenie jest ważne: ścieżka użytkownika w przeglądarce może działać, podczas gdy dostęp maszynowy, język, typy linków lub przypadki błędów są wadliwe. Dokładnie takie rozbieżności pozostają niewidoczne przy samym teście skanowania.

Plan odbioru w siedmiu krokach

1. Ustalenie reprezentatywnych testowych identyfikatorów URI

Nie zaczynaj od jednego przykładowego produktu. Przygotuj niewielki, wersjonowany zestaw testów:

co najmniej jeden prawidłowy identyfikator dla każdego obsługiwanego klucza głównego GS1;
przypadek GTIN bez kwalifikatora;
przypadki z partią lub numerem seryjnym, o ile obsługiwana jest taka szczegółowość;
składniowo nieprawidłowy identyfikator;
prawidłowy, ale nieznany identyfikator;
znany identyfikator bez żądanego typu linku.

Standard pozwala Resolverowi obsługiwać tylko podzbiór kluczy głównych GS1. Dla każdego obsługiwanego klucza głównego trzeba jednak w pełni przetwarzać jego kwalifikatory i atrybuty danych. Dlatego zestaw testowy musi odpowiadać rzeczywiście deklarowanym możliwościom, a nie ogólnemu przekazowi marketingowemu.

2. Sprawdzenie standardowego przekierowania i metod

Najpierw przetestuj zwykłe wywołanie bez specjalnych nagłówków. Oczekiwany jest deterministyczny link domyślny. Następnie sprawdź HEAD i OPTIONS: HEAD nie może stosować innej logiki routingu niż GET, a OPTIONS musi w zrozumiały sposób przedstawiać oferowane metody.

Minimalny test ręczny wygląda tak:

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

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

Udokumentuj kod statusu, Location, nagłówki pamięci podręcznej oraz liczbę przekierowań. Pętla przekierowań, losowy cel lub ścieżka różniąca się zależnie od metody oznacza błąd dyskwalifikujący, nawet jeśli smartfon ostatecznie wyświetli stronę.

3. Żądanie zestawu linków zamiast strony internetowej

Najważniejszym testem maszynowym jest zestaw linków:

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

RFC 9264 definiuje application/linkset+json jako samodzielną reprezentację JSON zbioru typowanych linków internetowych. GS1 zaostrza wymagania: wynik musi przejść walidację względem normatywnego schematu zestawu linków dla wersji 1.2.0. Dlatego sprawdzaj nie tylko, czy zwracany jest JSON, lecz także typ multimediów, schemat, bezwzględne identyfikatory URI celów, Anchor i relacje linków.

Szczególnie zdradliwe są formalnie prawidłowe, lecz merytorycznie błędne zestawy linków: na przykład podręcznik pod typem linku przeznaczonym dla strony z informacjami o produkcie albo cel dotyczący serii na poziomie GTIN. Dlatego walidacja schematu i fixture'y merytoryczne muszą być stosowane razem.

4. Kontrola opisu Resolvera

Zgodny z wymaganiami Resolver udostępnia pod adresem /.well-known/gs1resolver czytelny maszynowo opis. Zawiera on między innymi podstawę Resolvera i obsługiwane klucze główne. Plik musi przejść walidację względem schematu GS1 dla plików opisu Resolvera.

Test ten zapobiega częstej niespójności: usługa może obsługiwać więcej lub mniej, niż wynika z jej własnej deklaracji. Dlatego w odbiorze uwzględnij zarówno walidację schematu, jak i porównanie z rzeczywistymi przypadkami testowymi.

5. Testowanie CORS i negocjowania treści

CORS nie jest funkcją dodatkową. Standard wymaga go, aby aplikacje przeglądarkowe mogły komunikować się z Resolverem między domenami. Przetestuj co najmniej jeden dozwolony Origin przeglądarki oraz ścieżkę preflight. Sprawdź także, czy Accept: application/linkset+json i linkType=linkset zwracają spójne wyniki.

Dodaj test negatywny dla nieobsługiwanego typu multimediów. Usługa, która niezależnie od nagłówka Accept zawsze wysyła HTML, jest wprawdzie dostępna dla ludzi, ale nie zapewnia niezawodnego odczytu maszynowego.

6. Uwzględnienie języka, kontekstu i szczegółowości

Standard przewiduje Accept-Language oraz parametr zapytania context jako środki rozróżniania kilku pasujących linków. Nie każdy Resolver musi oferować każdą z tych możliwości. Jeśli obsługiwany jest język lub kontekst, reguły wyboru muszą być jednak powtarzalne.

Przetestuj więc dostępny język, niedostępny język oraz zdefiniowaną kolejność awaryjną. W przypadku GTIN, partii i numeru seryjnego obowiązuje ta sama zasada: szczegółowy identyfikator może uwzględniać istotne linki z wyższych poziomów, nie zacierając przy tym przyporządkowania merytorycznego. Zapisz oczekiwaną liczbę linków jako fixture; same testy snapshot sprawdzające kolejność są zbyt kruche.

7. Semantyczne rozróżnianie błędów

Kody błędów są częścią kontraktu. Standard Resolvera przewiduje dla składniowo nieprawidłowych identyfikatorów GS1 komunikat z HTTP 400. Gdy żądany jest konkretny, niedostępny typ linku, przekierowanie do celu domyślnego nie jest właściwą odpowiedzią. Takie przypadki trzeba odróżniać od nieznanego, lecz składniowo prawidłowego identyfikatora.

Sprawdź także, czy odpowiedzi błędów nie ujawniają szczegółów wewnętrznych, tokenów ani śladów stosu oraz czy GET, HEAD i żądania przeglądarkowe zachowują tę samą semantykę. Estetyczny dokument HTML z błędem nie naprawi nieprawidłowego kodu statusu.

Właściwe wykorzystanie pakietu testów GS1

Publiczny pakiet testów przyjmuje identyfikator URI tego rozwiązania i sprawdza zachowanie względem Resolvera 1.2.0. Dobrze nadaje się jako niezależny test dymny i zgodności. Na potrzeby akceptacji zapisz datę testu, testowany identyfikator URI, wersję standardu, wynik oraz — w razie potrzeby — odtwarzalne przypadki błędów.

Pakiet nie zastępuje jednak własnej regresji. GS1 wyraźnie wskazuje, że obecnie nie sprawdza kompresji. Jeśli Twój Resolver przetwarza binarne ciągi EPC lub inne skompresowane formy, potrzebujesz do tego osobnych wektorów testowych. Publiczny pakiet nie zna również Twoich merytorycznych typów linków ani wymagań dotyczących autoryzacji, dzierżawców lub dostępności.

Niezawodny proces łączy zatem trzy poziomy:

publiczny pakiet GS1 jako zewnętrzny test zgodności;
testy schematów zestawu linków i opisu Resolvera w CI;
własne testy end-to-end dla rzeczywistych identyfikatorów, ról, języków i awarii.

Co powinno znaleźć się w dowodzie akceptacji

Akceptacja jest powtarzalna dopiero wtedy, gdy wynik jest nie tylko widoczny w przeglądarce, lecz także udokumentowany. Dowód akceptacji powinien zawierać co najmniej wersję standardu i pakietu, czas testu, środowisko docelowe, testowe identyfikatory URI, oczekiwane typy linków, wyniki HTTP, walidację schematu, kontrolę CORS oraz znane wyjątki.

Stabilne elementy automatyzuj w CI, ale przed każdą istotną zmianą Resolvera wykonuj ukierunkowany zewnętrzny test względem publicznego pakietu. W ten sposób stwierdzenie „kod QR się otwiera” staje się weryfikowalną informacją o tożsamości, routingu i czytelnych maszynowo informacjach o produkcie.