Kule URIer!

Begrepet Cool URIs stammer fra dokumentet Cool URIs don’t change skrevet av Tim Berners Lee tilbake i 1998. Hvis du ikke vet hvem Tim er får du vel finne ut av det først.

Kort sagt: Kule URIer er de som ikke forandrer seg. De inneholder ikke spor av hvilken teknologi som er i bruk; de inneholder ikke navnet på forfatteren. De inneholder ting som klart identifiserer ressursen.

VG startet på nett på slutten av forrige århundre og brukte den gang URIer som så slik ut: http://www.vg.no/pub/vgart.hbs?artid=183653. De eksponerte en intern ID. De eksponerer filtypen “.hbs” og alle artiklene serveres fra samme “script” uansett hvor de er. Hvis de skiftet ut teknologien som brukte noe annet enn den interne IDen for å identifisere ressursen måtte de hatt en tjeneste som slår opp den nye ressursen og serverer det riktige innholdet, eller sender HTTP 301 Moved Permanently. VGs artikler fra 1998 virker fortsatt og det kan jo hende at de allerede har byttet ut eller skrevet om systemet flere ganger uten at man ser det fra utsiden. Det er jo kult :-)

Dagbladets URIer har ikke vært like men man får tak i sider tilbake fra 1998.
1996: http://www.dagbladet.no/961101/spo-1.html (virker ikke)
1998: http://www.dagbladet.no/sport/1998/05/30/103525.html (virker)
2000: http://www.dagbladet.no/sport/2000/03/01/196458.html&f=dbforside&t=Vi%20f%f8lger%20Champions%20League (virker ikke om ikke du tar bort query strengen)
2001: http://www.dagbladet.no/sport/2001/03/01/244742.html (virker)

Dagbladet eksponerer fortsatt “.html” extension som gir et sterkt inntrykk av de fortsatt publiserer statiske filer til en simpel webserver. HTML er jo ganske avlegs; kanskje man finner opp noe mye bedre og ønsker å gå over til det; da er man låst til at alle de gamle URIene hevder at de var HTML

Og selvfølgelig Aftenposten da:
1996: http://www.aftenposten.no/nyheter/forste/s23186.htm (virker ikke)
1998: http://www.aftenposten.no/nyheter/iriks/d21775.htm (virker ikke)
2000: http://www.aftenposten.no/cgi-bin/top.cgi?./nyheter/uriks/d157643.htm (virker ikke)
2002: http://www.aftenposten.no/nyheter/iriks/article.jhtml?articleID=301706 (virker nesten)
2004: http://www.aftenposten.no/nyheter/iriks/oslo/article.jhtml?articleID=721533 (virker nesten)
2006: http://www.aftenposten.no/nyheter/uriks/article1190511.ece (virker)

Begredelig. Jeg blir vel flamet for den siste URIen. Men for å ta mine kule URI-briller på: i 2000 forsøkte man seg på å legge inn et CGI-script med det resultat at alle URIene forandret seg. Og så byttet man publiseringssystem og alt forandret seg igjen. Jommen greide de ikke å gjøre det igjen i 2005 (men da med en manuell browserbasert redirect). Men det er verdt å legge merke til at innenriks og utenriks er to helt klare avdelinger og at de helt siden 1998 heter "iriks og “uriks”. Ergo er det rimelig å anta at slik informasjon faktisk hører hjemme i URIen til nyhetsmedier.

Historien er altså full av URIer som er laget av folk som ikke skjønner hva en URI faktisk er. Det er lett å slenge opp et CGI script og lage en PHP som henter en dings, men da sier du at URIen til dingsen din faktisk er /cgi-bin/en.php?dingsID=123… Tenk heller hvilke URIer som vil overleve systemskift etter systemskift uten sære omskrivninger i over hundre år! “/dingser/123” eller “/dingser/2007/rar-dings” eller “/2007/10/02/dingser/rar”… Så krever du at programvare du kjøper for å håndtere innholdet ditt skal holde seg til det URI skjemaet du velger.

Få URIer inn i kravspekken! Og utviklere: Tenk dere om! (Pass Opp! Stein kastet i glasshus!)

Kommentarer

En kul ting med Tim BL’s originale Cool URIs don’t change er selvfølgelig at URIen fortsatt ikke har forandret seg. Og kudos til VG som klarer å få sin del av verdensveven til å henge sammen etter så mange år!

De kuleste URLene har i mitt hode en annen funksjon også – de er informasjonsbærere for leseren.

Dagbladet sin kommer nær:

  • http://www.dagbladet.no/sport/1998/05/30/103525.html

Selv om det siste leddet ikke inneholder annet enn en intern referanse – og null informasjonsverdi for andre enn maskinene.

Denne, derimot, er forbilledlig:

  • http://arstechnica.com/reviews/os/ubuntu-gutsy-gibbon-review.ars

Til og med suffikset .ars vitner om stålkontroll over materien. Når du ser på seksjonsURL, så kommer det ennå tydeligere frem:

  • http://arstechnica.com/journals/apple.ars

Og siden du ber meg kaste en (liten) stein, så krever i praksis Escenic at vi skal annonsere for produktet deres for hver eneste saksside vi server, med sitt .ece-suffiks. Ikke at jeg har et bedre forslag, altså… :-)

Hehe. Jeg er (i ettertid) ikke særlig stolt over “.ece” nei… :-/ Aftonbladet.se bruker “.ab” suffiks.

Informasjonsbærere for sluttbrukeren er helt klart noe jeg trodde var kult ja. Som f.eks. å legge ut tittelen på et dokument som URLen sin. Men det som er enda viktigere er vel å unngå å bruke ting som tenderer til å forandre på seg f.eks. rått tittel som er blitt et populært SEO-triks i det siste.

Ars har flotte URLer ja. De har antakelig bestemt seg for URI struktur en eller annen gang. Kanskje det blir vanligere å gjøre det fremover? Det er jo faktisk et API som man må leve med i flere (hundre) år!

Og siden du ber meg kaste en (liten) stein, så krever i praksis Escenic at vi skal annonsere for produktet deres for hver eneste saksside vi server, med sitt .ece-suffiks. Ikke at jeg har et bedre forslag, altså… :-)

Eh, hva med .api :)

Ja, men er det nødvendigvis et motsetningsforhold her?

Informasjonsbærere for sluttbrukeren er helt klart noe jeg trodde var kult ja. Som f.eks. å legge ut tittelen på et dokument som URLen sin. Men det som er enda viktigere er vel å unngå å bruke ting som tenderer til å forandre på seg f.eks. rått tittel som er blitt et populært SEO-triks i det siste.

Pål: Hva mener du med motsetningsforhold?

Å bruke tittel som en del av URI’en er en farlig øvelse i hvertfall aviser. Som Erik sier forandres tittelen ofte. Man har ikke lyst på en URI som forandres med tittelen. Det å beholde orginal tittel i URI’en kan jo også få uheldige konsekvenser.

Jo, jeg ser det, men finnes det andre grep enn å bruke tittel og likevel beholde noe meningsbærende? Jeg tenkte i reting av en eller annen form for topic, kombinert med en publiseringsdatotidsstreng a la Dagbladet. Men kanskje det er for sårbart også?

Atom bruker “Slug:” header som forslag til hva fila skal hete (bildefilen eller atom enty’en). Dette er ikke tittelen men selvfølgelig er det nok en del bloggklienter som bruker tittelen og “vasker” den til bruk i URIen. Så hvis man forandrer tittelen beholder man den gamle URIen.

Spørsmålet er: ønsker man at sluttbrukerne skal forholde seg til URIen? Hvis noen legger ut et dokument bør de få et spørsmål: “Hva skal det hete (for evig og alltid)?”

Gosh, nei det ønsker vi absolutt ikke.

Enig med Pål her. Grunnen til at Google premierer friendly URLs (seksjon + tittel i URL) er jo fordi de er brukervennlige. At spammere misbruker er en annen sak, men ingen grunn til å droppe det for det.

Å bruke tittel som en del av URI’en er en farlig øvelse i hvertfall aviser. Som Erik sier forandres tittelen ofte.

Jepp, ser trøbbel med titler som forandrer seg. Det kan jo gjøre de brukeruvennlige. Spørsmålet er hvor stort problem det egentlig er? Gutfeelingen er at en ganske liten andel av titlene i nettavisene forandrer seg etter publish. Kanskje mindre enn fem prosent. Enda mindre i A-pressens nettaviser.

Jeg tror derfor jeg foretrekker orginaltittel i i URLen permanent, delvis fordi det sannsynlivis er en forsvinnende liten del der tittelen er vesentlig forandret fra orginalsaken (mye mindre enn de 5 prosentene igjen) slik at det kan misforstås, fremfor en mystisk tallrekke.

Ove, du mener at du vil ha vekk ID og lignende helt?

Jepp, jeg liker URLer som kan leses av mennesker og ikke maskiner. Det gjør det blant annet så ufattelig mye enklere når jeg blar i nettleser-loggen og skal finne gammel webside.

Mange gode poeng her:

  • URIer skal ikke forandre seg, ergo er de ikke direkte redaksjonell innhold
  • URIer kan godt utledes av tittelen (informasjonsbærende for mennesker)
  • URIer skal ikke inneholde ting som binder en til en spesiell implementasjon være det seg interne IDer eller annet meningsløst (eks. VG’s “/pub/”)

Hvis noen faktisk bryr seg om URIen til en spesiell ressurs (f.eks “følg kampen her” ble til “rosenborgseier”) såpass at man ønsker å forandre den må man servere HTTP 301 for de gamle URIene (IMHO). Problemet er at denne 301 må leve like lenge som ressursen for at dette skal virke, altså hundrevis av år. Å unngå problemet helt er jo best :-)

En avansert bruker vil jo lett skjønne hvordan han kan påvirke URIen og dermed slette originalsaken og legge den ut igjen og dermed få en ny URI

Grunnen til at alle putter interne IDer i URLene er så systemet kan finne artiklene i databasen. Men det betyr ikke at den interne identifikatoren er den eneste identifikatoren man kan bruke.

Noe jeg har lyst/tenkt til å implementere for Origo er URLer som ikke trenger å inneholde noen ID i det hele tatt, av typen http://origo.no/innlegg/kule_urier.

Alt vi trenger er en oppslagstabell og en måte å auto-unikifisere navnene; dersom noen så skriver enda en artikkel med tittelen “Kule URIer!” bruker vi kanskje en automatisk fallback til dato-kvalifisert URL: http://origo.no/innlegg/2007_11_09_kule_urier.

Og dersom forfatteren endrer tittelen lager vi en ny key, men oppdaterer den gamle med et flagg som sier at den utdatert – som gjør at vi gir 301 Moved Permanently og peker til den nyeste.

Alexander, noe slikt burde være et krav til ethvert CMS-system…

Forsiktig nå, Erik, forsiktig ;-)

(Klirr)

/me setter seg i tidsmaskinen og drar for å redigere en viss kravspekk

simen: Har du URI’en til den kravspekken? ;)

Hm… Hva er minst sansynlig montro?
At jeg disponerer en tidsmaskin eller at den kravspekken fortsatt har samme URI?

Du skrev den med andre ord i feil cms?

Hva med en url alla
http://origo.no/123545/innlegg/2007_11_09_kule_urier ?

Dvs at id’en ligger der, men at enden er fonuftig. Det er langt enklere å håndtere mhp endrede titler og andre festligheter.

Det fungerer sikkert, men poenget mitt var å unngå kompromisser. Det er enkelt å unngå å eksponere interne nøkler.

Annonse