Menneskelesbare URL-ar

[livarb]

Foreslår at ein også får med tittel i URL-en, slik at det blir meir menneskelesbart kva ein lenker til. Dette kan kanskje bidra til betre synleghet i søkemotorar også.

I dag har lenker i FDK kun UUID i URL-en. F.eks. for API-oppføring for Enhetsregisteret: https://fellesdatakatalog.brreg.no/apis/3b88f2d7-8531-4e5c-a0a0-e22ff96221df

F.eks.: https://fellesdatakatalog.brreg.no/apis/aapne-data-fra-enhetsregisteret/3b88f2d7-8531-4e5c-a0a0-e22ff96221df Kanskje også få med namnet på utgjevar.

Foreslår å nytte liknande oppsett som blant anna kode24.no nyttar. Eksempel: https://www.kode24.no/kodenytt/fa-kvinner-pa-norske-konferanser---flaut/70807366

Dersom ein fjernar den menneskeleglesbare biten, så fungerer framleis lenka: https://www.kode24.no/kodenytt/70807366

Men utan ID-en, så fungerer ikkje lenka, sidan den menneskelesbare delen kan endre seg dersom tittelen vert endra: https://www.kode24.no/kodenytt/fa-kvinner-pa-norske-konferanser---flaut

Dette er samme oppsett som regjeringen.no nyttar. Eksempel: https://www.regjeringen.no/no/aktuelt/nye-tiltak-mot-arbeidslivskriminalitet/id2628170/ https://www.regjeringen.no/id2628170/ (redirect til lenka over)

[livarb]

Er dette gjort, eller kva er grunnen til å lukke det? Tenker det framleis er ein god idè, også med tanke på SEO.

[joachim-me]

@livarb jeg var nok litt rask. Rydder i backloggen.

[KjerstiSteien]

@Lillebo Vet du om en elegant måte dette behovet kan løses på?

[Lillebo]

Absolutt, dette skal kunne løses ganske enkelt :+1:

Som @livarb sier så er det ID-en i URL-en som gjelder her. Alt utenom denne kan vi teknisk sett ignorere.

Det betyr at vi allerede nå kan transformere URL-ene våre fra dette: https://data.norge.no/information-models/677e3018-3392-30ba-8fe0-bcdced74c323

Til dette (hvor jeg har inkludert en menneskelesbar tittel): https://data.norge.no/information-models/677e3018-3392-30ba-8fe0-bcdced74c323?t=informasjonsmodell-for-dqv-ap-no

Og det funker allerede ut av boksen.

Det er også enkelt å generere kortere varianter av ID-ene våre hvor 677e3018-3392-30ba-8fe0-bcdced74c323 f.eks. blir oversatt til xg8QuT eller noe tilsvarende.

Da gjenstår det bare å kvitte oss med URL-parameteren ?t=, som også er lett å få til ved å definere noen routes som ignorerer alt etter ID-en.

Da kan vi f.eks. få URL-er som dette: https://data.norge.no/information-models/xg8QuT/informasjonsmodell-for-dqv-ap-no

Det eneste vi trenger å gjøre da er å gjøre et oppslag på hver request som oversetter xg8QuT tilbake til 677e3018-3392-30ba-8fe0-bcdced74c323 slik at vi får hentet riktig ressurs.

[KjerstiSteien]

Kult! Da tenker jeg vi må få dette opp på planen etter hvert. @KurtStian @NilsOveTen Tror dere det er behov for å vise den originale id-en i url? Kjenner dere til bruksområder for den?

[KurtStian]

@KjerstiSteien

Kult! Da tenker jeg vi må få dette opp på planen etter hvert. @KurtStian @NilsOveTen Tror dere det er behov for å vise den originale id-en i url? Kjenner dere til bruksområder for den?

Ser ut som Brønnøysundregistrene bruker dem for å hente ut beskrivelsene som JSON- se henvendelse på servicedesk fra 26.4.24 [Saksnummer: 2797] - TOPdesk - Sak 2024 11109

[KjerstiSteien]

Men det er via api? Trenger de å se dem i nettleseren da? Vil de kunne finne fdk-id et annet sted på siden? vi kunne startet med nåværende id + menneskelesbar tittel.

[NilsOveTen]

Vi har litt funksjonalitet rundt det å bare kunne spørre om andre serialiseringer fra samme URL som detaljsiden. Så hvis du endrer accept-header til json så får du json, accept-header til turtle så får du turtle osv

Vi kan gå bort fra det, holde logikken rundt den menneskelesbare URLen enkel nok til at nginx takler det eller at det blir node-backend tar seg av det.

[KurtStian]

Bruker å spørre om andre serialiseringer fra samme URL som detaljesiden hele tiden i forbindelse med testing. Sammenligne hva som vises som html mot det som finnes som turtle.

[KjerstiSteien]

Jeg ønsker ikke at vi går bort fra å kunne spørre om andre serialiseringer. Jeg synes det er en kul og nyttig funksjon. Litt usikker på om avsnitt to beskriver én eller tre mulige løsninger, @NilsOveTen ?

[NilsOveTen]

Da tror jeg transformasjonen av slugs til id må skje før nginx velger hvilke tjenester den skal videresende spørringene til, dunno om det er mulig. @Lillebo?

[Lillebo]

Hm, det er jeg også usikker på 🤷‍♂️

Men vi fortsetter vel uansett å støtte det gamle formatet på URL-ene samtidig? Kan en mellomløsning være at andre serialiseringer kun støttes på gamle URL-er?

[NilsOveTen]

Ja, det går sikkert. Så lenge vi gjør det mulig for nginx å skille mellom nye og gamle URL-er

[terjesyl]

Denne artikkelen har noen interessante perspektiver på hvordan lage mer lesbare, men fortsatt unike ID-er: https://parenteser.mattilsynet.io/datamodellering-ux/