Suite de pruebas de Resolver GS1: DPP-Links fiables antes de la puesta en producción

Un código QR que abre una página en el navegador todavía no demuestra que un resolver sea fiable. Para un resolver de GS1-Digital-Link cuenta todo el comportamiento HTTP: ¿qué identificadores se aceptan? ¿Cuál es el destino predeterminado? ¿Proporciona el servicio un conjunto de enlaces legible por máquinas? ¿Funcionan los accesos del navegador desde otros dominios? ¿Y notifican las solicitudes no válidas o no disponibles el error correcto?

Desde el 16 de enero de 2026 está disponible el estándar GS1-Conformant Resolver 1.2.0. La suite pública de pruebas de GS1 asociada ya se considera estable; su código se actualizó por última vez el 29 de junio de 2026. Así, una norma abstracta puede convertirse en una prueba concreta de aceptación. Este artículo muestra qué debe comprobarse antes de la puesta en producción, dónde están los límites de la suite de pruebas y qué evidencias deben formar parte de una aprobación técnica.

Un escaneo correcto solo es el principio

Un GS1 Digital Link contiene un identificador GS1 en una URI HTTPS. El resolver vincula este identificador con uno o varios recursos, como una página de producto, unas instrucciones, una ficha técnica o una interfaz de programación. Nuestro artículo introductorio explica el resolver de GS1-Digital-Link con un ejemplo en vivo. Para aprobar un entorno de producción, sin embargo, no basta con una redirección predeterminada correcta.

El estándar de Resolver 1.2.0 exige, entre otras cosas, HTTPS, compatibilidad con GET, HEAD y OPTIONS, Cross-Origin Resource Sharing (CORS), un enlace predeterminado identificable y una salida en forma de conjunto de enlaces. Con linkType=linkset o el encabezado Accept application/linkset+json, el resolver no debe redirigir. En su lugar, debe devolver los enlaces tipados disponibles como una representación independiente.

Esta separación es importante: la ruta humana del navegador puede funcionar mientras el acceso de máquinas, el idioma, los tipos de enlace o los casos de error presentan fallos. Precisamente estas desviaciones pasan inadvertidas en una simple prueba de escaneo.

Plan de aceptación en siete pasos

1. Definir URI de prueba representativas

No empiece con un único producto de muestra. Prepare una pequeña colección de pruebas versionada:

al menos un identificador válido por cada clave primaria GS1 compatible;
un caso de GTIN sin calificador;
casos con lote o número de serie, siempre que se admita este nivel de granularidad;
un identificador sintácticamente no válido;
un identificador válido, pero desconocido;
un identificador conocido sin el tipo de enlace solicitado.

El estándar permite que un resolver admita solo un subconjunto de las claves primarias GS1. Sin embargo, para cada clave primaria compatible deben procesarse por completo sus calificadores y atributos de datos. Por eso, el conjunto de pruebas debe corresponder a la capacidad realmente declarada, no a una afirmación de marketing generalizada.

2. Comprobar la redirección predeterminada y los métodos

Pruebe primero la llamada normal sin encabezados especiales. Se espera un enlace predeterminado determinista. Después siguen HEAD y OPTIONS: HEAD no debe utilizar una lógica de enrutamiento distinta de GET, y OPTIONS debe hacer comprensibles los métodos ofrecidos.

Una prueba manual mínima es la siguiente:

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

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

Documente el código de estado, Location, los encabezados de caché y el número de redirecciones. Un bucle de redirección, un destino aleatorio o una ruta que varíe según el método son errores de aprobación, aunque un teléfono inteligente termine mostrando una página.

3. Solicitar un conjunto de enlaces en lugar de una página web

La comprobación más importante para máquinas es el conjunto de enlaces:

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

RFC 9264 define application/linkset+json como una representación JSON independiente de un conjunto de enlaces web tipados. GS1 endurece el contrato: la salida debe validarse contra el esquema normativo de conjuntos de enlaces para la versión 1.2.0. Por tanto, no compruebe solo si se devuelve JSON, sino también el tipo de medio, el esquema, las URI de destino absolutas, el ancla y las relaciones de enlace.

Son especialmente engañosos los conjuntos de enlaces formalmente válidos, pero incorrectos desde el punto de vista funcional: por ejemplo, un manual con el tipo de enlace de una página de información de producto o un destino relacionado con una serie en el nivel de GTIN. Por ello, la validación del esquema y las fixtures funcionales deben utilizarse conjuntamente.

4. Revisar la descripción del resolver

Un resolver conforme proporciona en /.well-known/gs1resolver una descripción legible por máquinas. Esta incluye, entre otros datos, la raíz del resolver y las claves primarias compatibles. El archivo debe validarse contra el esquema de GS1 para los archivos de descripción del resolver.

Esta prueba evita una incoherencia frecuente: que el servicio pueda hacer más o menos de lo que afirma su propia descripción. Por eso, incluya en la aceptación tanto la validación del esquema como una comparación con casos de prueba reales.

5. Probar CORS y la negociación de contenido

CORS no es una función de comodidad. El estándar lo exige para que las aplicaciones basadas en navegador puedan comunicarse con el resolver entre distintos dominios. Pruebe al menos un origen de navegador permitido y la ruta de preflight. Compruebe además si Accept: application/linkset+json y linkType=linkset producen resultados coherentes.

Añada una prueba negativa para un tipo de medio no compatible. Un servicio que envía siempre HTML, independientemente del encabezado Accept, puede ser accesible para las personas, pero no es fiable para las máquinas.

6. Cubrir idioma, contexto y granularidad

El estándar contempla Accept-Language y el parámetro de consulta context como medios para distinguir entre varios enlaces adecuados. No todos los resolvers tienen que ofrecer cada variante. Sin embargo, cuando se admiten el idioma o el contexto, las reglas de selección deben ser reproducibles.

Por tanto, pruebe un idioma disponible, uno no disponible y un orden de fallback definido. Para GTIN, el lote y el número de serie se aplica el mismo principio: un identificador más específico puede tener en cuenta enlaces relevantes de niveles superiores sin desdibujar la asignación funcional. Registre como fixture el conjunto de enlaces esperado; las pruebas de snapshot basadas únicamente en el orden son demasiado frágiles.

7. Diferenciar semánticamente los errores

Los códigos de error forman parte del contrato. El estándar del resolver establece para los identificadores GS1 sintácticamente no válidos un mensaje con HTTP 400. Si se solicita un tipo de enlace concreto que no está disponible, redirigir al destino predeterminado no es la respuesta correcta. Estos casos deben distinguirse de un identificador desconocido, pero sintácticamente válido.

Compruebe también que las respuestas de error no revelen detalles internos, tokens ni trazas de pila, y que GET, HEAD y las solicitudes basadas en navegador mantengan la misma semántica. Un documento de error HTML atractivo no puede compensar un código de estado incorrecto.

Cómo utilizar correctamente la suite de pruebas de GS1

La suite pública de pruebas recibe una URI de Digital-Link y comprueba el comportamiento frente a Resolver 1.2.0. Es adecuada como comprobación independiente de humo y de conformidad. Para la aprobación, guarde la fecha de la prueba, la URI probada, la versión del estándar, el resultado y, cuando proceda, los casos de error reproducibles.

Sin embargo, la suite no sustituye a una regresión propia. GS1 señala expresamente que actualmente no comprueba la compresión. Si su resolver procesa cadenas binarias EPC u otras formas comprimidas, necesitará vectores de prueba independientes. Asimismo, la suite pública no conoce sus tipos de enlace funcionales ni sus requisitos de autorización, multiarrendamiento o disponibilidad.

Por tanto, un proceso fiable combina tres niveles:

la suite pública de GS1 como comprobación externa de conformidad;
pruebas de esquema para el conjunto de enlaces y la descripción del resolver en CI;
pruebas propias de extremo a extremo para identificadores reales, roles, idiomas y fallos.

Qué debe incluir la evidencia de aprobación

Una aceptación solo es repetible cuando el resultado no solo es visible en el navegador, sino que también está documentado. La evidencia de aprobación debe incluir como mínimo la versión del estándar y de la suite, el momento de la prueba, el entorno de destino, las URI de prueba, los tipos de enlace esperados, los resultados HTTP, la validación del esquema, la comprobación de CORS y las excepciones conocidas.

Automatice en CI las partes estables, pero mantenga una ejecución externa específica contra la suite pública antes de cada cambio importante del resolver. Así, «el código QR se abre» se convierte en una afirmación verificable sobre identidad, enrutamiento e información de producto legible por máquinas.