GS1 Resolver Test Suite: DPP-linkkien luotettava tarkistus ennen käyttöönottoa

QR-koodi, joka avaa selaimessa sivun, ei vielä todista resolverin luotettavuutta. GS1-tunnisteiden resolverissa ratkaisevaa on HTTP-käyttäytyminen kokonaisuudessaan: Mitkä tunnisteet hyväksytään? Mikä kohde on oletusarvoinen? Palauttaako palvelu koneellisesti luettavan linkkijoukon? Toimivatko selainpyynnöt muista toimialueista? Ja ilmoittavatko virheelliset tai saavuttamattomat pyynnöt oikean virheen?

GS1-Conformant Resolver Standard 1.2.0 on ollut saatavilla 16. tammikuuta 2026 lähtien. Sen julkinen GS1-testisarja on sittemmin vakiintunut, ja sen koodi päivitettiin viimeksi 29. kesäkuuta 2026. Näin abstraktista standardista voidaan tehdä konkreettinen hyväksymistesti. Tässä artikkelissa kerrotaan, mitä ennen käyttöönottoa tulisi tarkistaa, missä testisarjan rajat kulkevat ja mitä todisteita tekniseen hyväksyntään kuuluu.

Onnistunut skannaus on vasta alku

Yksi GS1 Digital Link sisältää GS1-tunnisteen HTTPS-URI:ssa. Resolver yhdistää tämän tunnisteen yhteen tai useampaan resurssiin, kuten tuotesivuun, käyttöohjeeseen, tietolehteen tai ohjelmointirajapintaan. Perusteita käsittelevässä artikkelissamme esitellään GS1-tunnisteiden resolver live-esimerkin avulla. Tuotantokäyttöön hyväksymiseen ei kuitenkaan riitä onnistunut oletusarvoinen uudelleenohjaus.

Resolver-standardi 1.2.0 edellyttää muun muassa HTTPS:ää, tuen tarjoamista muodoille GET, HEAD ja OPTIONS, Cross-Origin Resource Sharingia (CORS), tunnistettavaa oletuslinkkiä sekä linkkijoukon palautusta. Kun käytetään linkType=linkset-pyyntöä tai Accept-otsaketta application/linkset+json, resolver ei saa uudelleenohjata. Sen on sen sijaan palautettava saatavilla olevat tyypitetyt linkit itsenäisenä esityksenä.

Tämä erottelu on tärkeä: ihmisen selaimella käyttämä polku voi toimia, vaikka konekäyttö, kieli, linkkityypit tai virhetilanteet olisivat rikki. Juuri tällaiset poikkeamat jäävät näkymättömiksi pelkällä skannaustestillä.

Hyväksymissuunnitelma seitsemässä vaiheessa

1. Määritä edustavat testi-URI:t

Älä aloita yhdestä ainoasta esimerkkituotteesta. Kokoa pieni, versioitu testikokoelma:

vähintään yksi kelvollinen tunniste kutakin tuettua GS1-pääavainta kohden;
yksi GTIN-tapaus ilman tarkenninta;
eriä tai sarjanumeroita sisältävät tapaukset, jos tällaista tarkkuustasoa tuetaan;
syntaktisesti virheellinen tunniste;
kelvollinen mutta tuntematon tunniste;
tunnettu tunniste ilman pyydettyä linkkityyppiä.

Standardi sallii resolverin tukea vain osaa GS1-pääavaimista. Jokaisen tuetun pääavaimen tarkentimet ja tietoattribuutit on kuitenkin käsiteltävä täydellisesti. Siksi testijoukon on vastattava tosiasiallisesti ilmoitettua kyvykkyyttä, ei yleisluontoista markkinointiväitettä.

2. Tarkista oletusarvoinen uudelleenohjaus ja menetelmät

Testaa tavallinen kutsu ensin ilman erityisiä otsakkeita. Odotuksena on deterministinen oletuslinkki. Sen jälkeen testataan HEAD ja OPTIONS: HEAD ei saa käyttää muuta reitityslogiikkaa kuin GET, ja OPTIONS:n on tehtävä tarjotut menetelmät ymmärrettäviksi.

Yksinkertainen manuaalinen testi näyttää tältä:

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

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

Kirjaa tilakoodi, Location, välimuistiotsakkeet ja uudelleenohjausten määrä. Uudelleenohjaussilmukka, sattumanvarainen kohde tai menetelmäkohtaisesti poikkeava polku on hyväksynnän este, vaikka älypuhelin lopulta näyttäisikin sivun.

3. Pyydä linkkijoukkoa verkkosivun sijaan

Tärkein koneellinen tarkistus koskee linkkijoukkoa:

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

RFC 9264 määrittelee application/linkset+json:n tyypitettyjen verkkolinkkien joukon itsenäiseksi JSON-esitykseksi. GS1 tiukentaa vaatimusta: tuloksen on läpäistävä version 1.2.0 normatiivisen linkkijoukkokaavion validointi. Älä siis tarkista vain JSON-tuloksen saapumista, vaan myös mediatyyppi, kaavio, absoluuttiset kohde-URI:t, ankkuri ja linkkirelaatiot.

Erityisen hankalia ovat muodollisesti kelvolliset mutta sisällöllisesti väärät linkkijoukot: esimerkiksi käyttöopas tuotetietosivun linkkityypillä tai sarjakohtainen kohde GTIN-tasolla. Kaavion validointi ja sisällölliset testiaineistot kuuluvat siksi yhteen.

4. Tarkista resolverin kuvaus

Yhteensopiva resolver tarjoaa osoitteessa /.well-known/gs1resolver koneellisesti luettavan kuvauksen. Siinä ilmoitetaan muun muassa resolverin juuri ja tuetut pääavaimet. Tiedoston on läpäistävä resolverin kuvaustiedostojen GS1-kaavion validointi.

Tämä testi estää yleisen ristiriidan: palvelu voi tarjota enemmän tai vähemmän kuin itsekuvauksessa väitetään. Ota siksi hyväksyntään sekä kaavion validointi että vertailu todellisiin testitapauksiin.

5. Testaa CORS ja sisältöneuvottelu

CORS ei ole mukavuusominaisuus. Standardi edellyttää sitä, jotta selainpohjaiset sovellukset voivat käyttää resolveria toimialueiden yli. Testaa vähintään yksi sallittu selaimen Origin sekä esipyynnön polku. Tarkista lisäksi, palauttavatko Accept: application/linkset+json ja linkType=linkset yhdenmukaiset tulokset.

Lisää negatiivinen testi tukemattomalle mediatyypille. Palvelu, joka lähettää aina HTML:ää riippumatta Accept-otsakkeesta, on ihmisille saavutettava mutta ei luotettavasti koneellisesti luettava.

6. Kattaa kieli, konteksti ja tarkkuustaso

Standardi määrittelee Accept-Language:n ja kyselyparametrin context keinoiksi erottaa toisistaan useita sopivia linkkejä. Jokaisen resolverin ei tarvitse tarjota jokaista vaihtoehtoa. Jos kieliä tai kontekstia tuetaan, valintasääntöjen on kuitenkin oltava toistettavia.

Testaa siksi olemassa oleva kieli, puuttuva kieli ja määritelty varajärjestys. GTIN:n, erän ja sarjanumeron kohdalla pätee sama periaate: tarkka tunniste saa ottaa huomioon ylempien tasojen olennaiset linkit, mutta sisällöllinen kohdistus ei saa hämärtyä. Kirjaa odotettu linkkimäärä testiaineistoksi; pelkät järjestykseen perustuvat snapshot-testit ovat liian herkkiä.

7. Erottele virheet semanttisesti

Virhekoodit ovat osa sopimusta. Resolver-standardi edellyttää syntaktisesti virheellisille GS1-tunnisteille HTTP 400 -ilmoitusta. Kun pyydetään tiettyä, saavuttamatonta linkkityyppiä, uudelleenohjaus oletuskohteeseen ei ole oikea vastaus. Tällaiset tapaukset on erotettava tuntemattomasta mutta syntaktisesti kelvollisesta tunnisteesta.

Tarkista myös, etteivät virhevastaukset paljasta sisäisiä tietoja, tunnuksia tai pinovirheitä ja että GET, HEAD sekä selainpohjaiset pyynnöt säilyttävät saman semantiikan. Hieno HTML-virhedokumentti ei korjaa väärää tilakoodia.

GS1-testisarjan oikea käyttö

Julkinen testisarja vastaanottaa tunniste-URI:n ja tarkistaa käyttäytymisen Resolver 1.2.0:aa vasten. Se soveltuu hyvin riippumattomaksi savu- ja yhteensopivuustestiksi. Tallenna hyväksyntää varten testipäivä, testattu URI, standardiversio, tulos ja tarvittaessa toistettavat virhetapaukset.

Testisarja ei kuitenkaan korvaa omaa regressiotestausta. GS1 huomauttaa nimenomaisesti, ettei se tällä hetkellä tarkista pakkausta. Jos resolver käsittelee EPC-binäärimerkkijonoja tai muita pakattuja muotoja, tarvitset niitä varten erilliset testivektorit. Julkinen sarja ei myöskään tunne omia sisällöllisiä linkkityyppejäsi eikä valtuutus-, vuokraaja- tai saatavuusvaatimuksiasi.

Luotettava prosessi yhdistää siksi kolme tasoa:

julkinen GS1-sarja ulkoisena yhteensopivuustestinä;
linkkijoukon ja resolverin kuvauksen kaaviotestit CI:ssä;
omat päästä päähän -testit todellisille tunnisteille, rooleille, kielille ja häiriöille.

Mitä hyväksyntätodisteeseen kuuluu

Hyväksyntä on toistettavissa vasta, kun tulos ei ole vain selaimessa nähtävissä vaan myös dokumentoitu. Hyväksyntätodisteen tulisi sisältää vähintään standardi- ja testisarjaversio, testiajankohta, kohdeympäristö, testi-URI:t, odotetut linkkityypit, HTTP-tulokset, kaavion validointi, CORS-tarkistus ja tunnetut poikkeukset.

Automatisoi vakaat osat CI:ssä, mutta suorita ennen jokaista merkittävää resolver-muutosta kohdennettu ulkoinen ajo julkista sarjaa vasten. Näin lauseesta ”QR-koodi avautuu” tulee todennettava väite tunnisteesta, reitityksestä ja koneellisesti luettavista tuotetiedoista.