Тестов пакет за резолвери: DPP-връзките да бъдат надеждно проверени преди пускане в продукция

QR код, който отваря страница в браузъра, все още не доказва надежден резолвер. За резолвер на технологията за идентификатори на GS1 е важно цялостното HTTP поведение: Какви идентификатори се приемат? Коя цел е стандартната? Предоставя ли услугата машинночетим набор от връзки? Работи ли достъпът от браузър през други домейни? И съобщават ли невалидните или недостъпните заявки правилната грешка?

От 16 януари 2026 г. е наличен GS1-Conformant Resolver Standard 1.2.0. Свързаният с него публичен тестов пакет на GS1 вече се счита за стабилен; кодът му е актуализиран за последно на 29 юни 2026 г. Така една абстрактна норма може да се превърне в конкретен приемателен тест. В тази статия е показано какво трябва да се провери преди пускане в продукция, къде са границите на тестовия пакет и какви доказателства трябва да влязат в техническото одобрение.

Успешното сканиране е само началото

Един GS1 Digital Link съдържа GS1 идентификатор в HTTPS URI. Резолверът свързва този идентификатор с един или повече ресурси, например продуктова страница, ръководство, информационен лист или програмен интерфейс. Нашата основна статия обяснява резолвера за идентификатори на GS1 с пример на живо. За пускане в продукция обаче не е достатъчно успешно стандартно пренасочване.

Стандартът за резолвери 1.2.0 изисква, наред с другото, HTTPS, поддръжка на GET, HEAD и OPTIONS, Cross-Origin Resource Sharing (CORS), разпознаваема стандартна връзка и изход във формат набор от връзки. При linkType=linkset или заглавка Accept application/linkset+json резолверът не трябва да пренасочва. Вместо това той трябва да върне наличните типизирани връзки като самостоятелно представяне.

Това разделение е важно: пътят през човешкия браузър може да работи, докато машинният достъп, езикът, типовете връзки или сценариите с грешки са неизправни. Точно такива отклонения остават невидими при обикновен тест със сканиране.

Планът за приемане в седем стъпки

1. Определете представителни тестови URI

Не започвайте с един-единствен примерен продукт. Съставете малка, версионирана тестова колекция:

поне един валиден идентификатор за всеки поддържан първичен ключ на GS1;
случай с GTIN без квалификатор;
случаи с партида или сериен номер, ако тази детайлност се поддържа;
синтактично невалиден идентификатор;
валиден, но непознат идентификатор;
познат идентификатор без заявения тип връзка.

Стандартът позволява на един резолвер да поддържа само подмножество от първичните ключове на GS1. За всеки поддържан първичен ключ обаче неговите квалификатори и атрибути на данните трябва да се обработват изцяло. Затова тестовият набор трябва да съответства на действително декларираните възможности, а не на общо маркетингово твърдение.

2. Проверете стандартното пренасочване и методите

Първо тествайте нормалното извикване без специални заглавки. Очаква се детерминирана стандартна връзка. Следват HEAD и OPTIONS: HEAD не трябва да използва различна логика за маршрутизиране от GET, а OPTIONS трябва да прави поддържаните методи разбираеми.

Минимален ръчен тест изглежда така:

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

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

Документирайте кода на състоянието, Location, заглавките за кеширане и броя на пренасочванията. Цикъл на пренасочване, случайна цел или път, който се различава според метода, е грешка при приемането, дори ако смартфонът в крайна сметка покаже страница.

3. Заявете набор от връзки вместо уебстраница

Най-важната машинна проверка е наборът от връзки:

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

RFC 9264 определя application/linkset+json като самостоятелно JSON представяне на множество типизирани уеб връзки. GS1 затяга изискванията: изходът трябва да преминава валидация спрямо нормативната схема за набор от връзки за версия 1.2.0. Затова проверявайте не само дали се връща JSON, но и типа на медията, схемата, абсолютните целеви URI, Anchor и релациите на връзките.

Особено коварни са формално валидните, но съдържателно неправилни набори от връзки: например ръководство под типа връзка за продуктова информационна страница или цел, свързана със серия, на ниво GTIN. Затова валидацията на схемата и съдържателните тестови фикстури трябва да се използват заедно.

4. Контролирайте описанието на резолвера

Съответстващият на стандарта резолвер предоставя машинночетимо описание на /.well-known/gs1resolver. То посочва, наред с другото, основата на резолвера и поддържаните първични ключове. Файлът трябва да преминава валидация спрямо схемата на GS1 за файлове с описания на резолвери.

Този тест предотвратява често срещано несъответствие: услугата може да може повече или по-малко, отколкото твърди собственото ѝ описание. Затова включете в приемането както валидация на схемата, така и сравнение с реални тестови случаи.

5. Тествайте CORS и договарянето на съдържанието

CORS не е удобна екстра. Стандартът го изисква, за да могат браузърните приложения да се обръщат към резолвера от различни домейни. Тествайте поне един разрешен браузърен Origin и пътя за предварителната заявка. Проверете също дали Accept: application/linkset+json и linkType=linkset дават съгласувани резултати.

Добавете отрицателен тест за неподдържан тип медия. Услуга, която независимо от заглавката Accept винаги изпраща HTML, е достъпна за хора, но не е надеждно машинночетима.

6. Обхванете език, контекст и детайлност

Стандартът предвижда Accept-Language, както и параметъра на заявката context, като средства за разграничаване между няколко подходящи връзки. Не всеки резолвер трябва да предлага всеки вариант. Ако се поддържат език или контекст, правилата за избор обаче трябва да бъдат възпроизводими.

Затова тествайте наличен език, неналичен език и определена последователност за резервен избор. За GTIN, партида и сериен номер важи същият принцип: По-детайлен идентификатор може да взема предвид релевантни връзки от по-високи нива, без да размива съдържателното съответствие. Запишете очаквания брой връзки като фикстура; чистите snapshot тестове на последователността са твърде крехки.

7. Разграничете грешките семантично

Кодовете за грешки са част от договора. Стандартът за резолвери предвижда за синтактично невалидни GS1 идентификатори съобщение с HTTP 400. Когато е заявен конкретен недостъпен тип връзка, пренасочването към стандартната цел не е правилният отговор. Тези случаи трябва да се разграничават от непознат, но синтактично валиден идентификатор.

Проверете също дали отговорите за грешки не разкриват вътрешни подробности, токени или stack trace и дали GET, HEAD и браузърните заявки запазват една и съща семантика. Атрактивен HTML документ за грешка не може да компенсира неправилен код на състоянието.

Как да използвате правилно тестовия пакет на GS1

Публичният тестов пакет приема URI на Digital Link и проверява поведението спрямо Resolver 1.2.0. Той е подходящ като независима проверка за димни тестове и съответствие. За одобрението запазвайте датата на теста, тествания URI, версията на стандарта, резултата и евентуално възпроизводимите случаи на грешка.

Пакетът обаче не заменя собствената регресия. GS1 изрично посочва, че понастоящем той не проверява компресията. Ако резолверът ви обработва EPC двоични низове или други компресирани форми, ще са ви нужни отделни тестови вектори. Публичният пакет също не познава вашите съдържателни типове връзки, нито изискванията ви за оторизация, мултитенантност или наличност.

Затова надеждният процес комбинира три нива:

публичният пакет на GS1 като външна проверка за съответствие;
тестове на схемите за набора от връзки и описанието на резолвера в CI;
собствени end-to-end тестове за реални идентификатори, роли, езици и откази.

Какво трябва да съдържа доказателството за одобрение

Приемането може да се повтори едва когато резултатът не само се вижда в браузъра, но и е документиран. Доказателството за одобрение трябва най-малкото да съдържа версията на стандарта и пакета, момента на теста, целевата среда, тестовите URI, очакваните типове връзки, HTTP резултатите, валидацията на схемата, проверката на CORS и известните изключения.

Автоматизирайте стабилните части в CI, но преди всяка съществена промяна на резолвера извършвайте целенасочено външно изпълнение спрямо публичния пакет. Така „QR кодът се отваря“ се превръща в проверимо твърдение за идентичността, маршрутизирането и машинночетимата продуктова информация.