Uniform resource identifier (URI)

Een uniform resource identifier (URI) is een reeks tekens die een bron eenduidig aanwijst. Die bron kan een webpagina zijn, maar ook een e-mailadres, een bestand of zelfs een boek.

Je gebruikt URI's elke dag. Vaak zonder dat je het weet. Elke link waar je op klikt is er een, net als het adres in de adresbalk van je browser.

Simpel gezegd is een URI een vaste naam of een vast adres. Op het web heet het ding dat hij aanwijst een resource. De regels voor URI's staan in RFC 3986, de technische standaard van de Internet Engineering Task Force (IETF). Daardoor lezen browsers, servers en apps over de hele wereld een URI op dezelfde manier.

Een URI hoeft niet altijd naar een plek te wijzen. Soms is het alleen een naam. Het belangrijkste is dat hij een resource herkenbaar maakt en niet te verwarren is met een andere.

Wat betekent uniform resource identifier?

De naam vertelt al veel over wat een URI doet. Elk van de drie woorden heeft een eigen rol:

• Uniform: iedereen gebruikt dezelfde regels en dezelfde opbouw. Zo kunnen heel verschillende systemen met dezelfde URI werken.

• Resource: het ding waar de URI naar verwijst. Dat kan van alles zijn.

• Identifier: de URI maakt een resource herkenbaar, net zoals een kenteken een auto herkenbaar maakt.

Wat is een resource?

Het woord resource is in deze context heel breed. Het gaat niet alleen om webpagina's. Volgens de standaard kan een resource onder meer zijn:

• een webpagina, afbeelding of pdf

• een dienst, zoals een API die gegevens teruggeeft

• een fysiek object, zoals een boek met een ISBN

• een persoon of een organisatie

• een abstract begrip, zoals een relatie tussen twee dingen

Een URI van een fysiek boek kun je niet openen in je browser. Toch is het een geldige URI, omdat hij precies dat ene boek aanwijst.

Waarom is een URI belangrijk?

Zonder een vaste manier om dingen te benoemen werkt het web niet. Een link moet in elke browser hetzelfde betekenen. Een API-verzoek moet bij elke server op dezelfde manier binnenkomen.

URI's zorgen daarvoor. Ze zijn om een paar redenen onmisbaar:

• Eén standaard: elk systeem leest een URI volgens dezelfde regels.

• Uniek: een URI wijst precies één resource aan.

• Uitbreidbaar: via schemes zoals https, mailto en tel werkt hetzelfde systeem voor heel verschillende soorten bronnen.

• Koppelbaar: doordat alles een eigen URI heeft, kunnen bronnen naar elkaar verwijzen. Dat is de basis van hyperlinks en linked data.

Ook voor SEO speelt de URI een rol. Zoekmachines zien elke unieke URI als een aparte pagina. Staat dezelfde inhoud op meerdere URI's, dan krijg je dubbele content. Vaste en duidelijke URI's helpen dat te voorkomen.

Het verschil tussen een URI, URL en URN

URI, URL en URN worden vaak door elkaar gebruikt. Toch betekenen ze niet hetzelfde. URI is de overkoepelende term. URL en URN zijn twee soorten URI's.

Wat is een URL?

Een URL (uniform resource locator) is een URI die vertelt waar een resource staat en hoe je hem ophaalt. Het begin van de URL geeft het protocol aan, zoals https of ftp. Daarna volgt de plek, bijvoorbeeld:

https://www.voorbeeld.nl/contact

Elke URL is dus een URI. Maar niet elke URI is een URL.

Wat is een URN?

Een URN (uniform resource name) is een URI die een resource alleen een vaste naam geeft. Hij zegt niets over waar de bron staat. Een URN blijft daardoor geldig, ook als de bron verhuist of niet meer online staat. Dit voorbeeld wijst een boek aan via het ISBN:

urn:isbn:0451450523

URI, URL en URN naast elkaar

De tabel hieronder zet de drie begrippen op een rij.

In de praktijk vervaagt het verschil. De officiële standaard noemt URL en URN vooral een rol die een URI kan hebben. Browsers en webontwikkelaars zeggen juist bijna altijd URL, ook als ze technisch gezien een URI bedoelen.

Hoe is een URI opgebouwd?

Elke URI volgt dezelfde vaste opbouw. Sommige delen zijn verplicht, andere niet. De algemene vorm ziet er zo uit:

scheme:[//authority]path[?query][#fragment]

Delen tussen blokhaken mag je weglaten. Neem deze URI als voorbeeld:

https://www.voorbeeld.nl:8080/blog/artikel?id=42#reacties

In de tabel zie je welk deel wat doet.

Scheme

Het scheme staat altijd vooraan en eindigt met een dubbele punt. Het bepaalt hoe de rest van de URI gelezen wordt. Bekende schemes zijn http, https, ftp, mailto, tel en file.

De IANA houdt een officiële lijst bij van alle geregistreerde schemes. Hoofdletters maken bij een scheme niet uit, maar de standaard raadt kleine letters aan.

Authority

De authority komt na twee slashes (//). Meestal is dit de domeinnaam of het IP-adres van de server. De authority kan uit drie delen bestaan:

• Userinfo: een gebruikersnaam met een @ erachter, zoals jan@ in ftp://jan@ftp.voorbeeld.nl. Dit deel is optioneel. Een wachtwoord in de URI zetten wordt sterk afgeraden.

• Host: de domeinnaam of het IP-adres, zoals www.voorbeeld.nl.

• Port: het poortnummer na een dubbele punt, zoals :8080. Laat je hem weg, dan geldt de standaardpoort van het scheme. Voor https is dat 443, voor http 80.

Niet elke URI heeft een authority. In mailto:info@voorbeeld.nl staan bijvoorbeeld geen twee slashes.

Path

Het path wijst de resource aan binnen de host. Het bestaat uit delen met een slash ertussen, zoals /blog/artikel. Vaak lijkt het op een mappenstructuur.

Dat hoeft niet zo te zijn. De server bepaalt zelf wat een path betekent. Een path kan ook leeg zijn, zoals bij https://www.voorbeeld.nl.

Query

De query begint met een vraagteken. Hij geeft extra gegevens mee die niet in het path passen. Meestal zijn dat paren van een naam en een waarde, met een & ertussen:

?id=42&taal=nl

Die vorm met = en & is een gewoonte, geen harde regel uit de standaard. Je ziet queries vaak bij zoekopdrachten, filters en trackingcodes zoals UTM-parameters.

Fragment

Het fragment begint met een hekje (#). Het wijst een deel binnen de resource aan, zoals een kop op een pagina.

Een browser stuurt het fragment niet mee naar de server. Het blijft in de browser zelf. Die gebruikt het bijvoorbeeld om meteen naar het juiste stuk van een pagina te scrollen.

Voorbeelden van URI's

URI's komen in veel vormen voor. Het scheme aan het begin vertelt meteen met wat voor soort bron je te maken hebt. De tabel hieronder laat zien hoe verschillend ze kunnen zijn.

Alleen de eerste twee halen echt iets op van een server. De rest opent een app, wijst iets op je eigen apparaat aan of geeft alleen een naam. Toch volgen ze allemaal dezelfde opbouw.

Absolute en relatieve URI's

Op websites zie je niet altijd de volledige URI. Vaak staat er in de code maar een deel van. Dat heet een relatieve verwijzing. In de standaard heet zo'n verwijzing een URI reference.

Absolute URI

Een absolute URI is compleet. Hij begint met een scheme en bevat alles wat nodig is om de resource te vinden:

https://www.voorbeeld.nl/blog/artikel

Een absolute URI werkt overal. Het maakt niet uit op welke pagina hij staat.

Relatieve URI

Een relatieve URI mist een deel, meestal het scheme en de host. Hij werkt alleen samen met een basis-URI. Dat is vaak het adres van de pagina waar je op staat. Er zijn een paar vormen:

• /contact: begint bij de root van dezelfde host.

• artikel-2: staat in dezelfde map als de huidige pagina.

• ../over-ons: gaat eerst één map omhoog.

• //cdn.voorbeeld.nl/logo.png: neemt het scheme van de huidige pagina over.

• #reacties: wijst naar een stuk van dezelfde pagina.

Relatieve URI's maken een website makkelijker te verhuizen naar een ander domein. De links blijven dan gewoon werken.

Hoe een relatieve URI wordt omgezet

Het omzetten van een relatieve naar een absolute URI heet resolution. De browser neemt de basis-URI en vult de ontbrekende delen aan. Stel dat je op https://www.voorbeeld.nl/blog/artikel staat. Dan worden de verwijzingen zo omgezet:

De regels voor deze stap staan precies beschreven in de standaard. Daardoor komt elke browser op dezelfde uitkomst uit.

Speciale tekens in een URI

Een URI mag niet zomaar elk teken bevatten. De standaard gebruikt alleen tekens uit ASCII: Latijnse letters, cijfers en een aantal leestekens. Voor alle andere tekens is er een oplossing.

Gereserveerde en vrije tekens

De standaard deelt de toegestane tekens in twee groepen in:

• Vrije tekens (unreserved): de letters A tot en met Z, de cijfers 0 tot en met 9 en de tekens - . _ ~. Deze mag je overal gebruiken.

• Gereserveerde tekens (reserved): tekens met een speciale functie, zoals : / ? # [ ] @ ! $ & ' ( ) * + , ; =. Ze scheiden de delen van een URI van elkaar.

Wil je een gereserveerd teken gebruiken als gewone tekst? Dan moet je het coderen. Anders denkt het systeem dat het teken een functie heeft.

Percent-encoding

Percent-encoding zet een teken om naar een procentteken met twee hexadecimale cijfers. Die cijfers staan voor de waarde van het teken in bytes. Een paar bekende voorbeelden staan in deze tabel.

Een zoekopdracht naar "café amsterdam" wordt in een URI dus ?q=caf%C3%A9%20amsterdam. Browsers doen dit meestal vanzelf. In de adresbalk zie je vaak nog de leesbare versie.

In formulieren zie je een spatie soms als een +. Die regel komt uit een aparte standaard voor formulierdata, niet uit de URI-standaard zelf.

IRI: URI's met internationale tekens

Een gewone URI kent alleen ASCII. Voor tekens als é, ü of Chinese tekens bestaat de IRI (internationalized resource identifier), vastgelegd in RFC 3987. Een IRI mag wel Unicode-tekens bevatten.

Bij het versturen wordt een IRI omgezet naar een gewone URI. Het path en de query krijgen percent-encoding. Domeinnamen met speciale tekens gaan via Punycode. Zo wordt bücher.de bijvoorbeeld xn--bcher-kva.de.

Waar kom je URI's tegen?

URI's zitten in bijna alles wat met het web te maken heeft. Op deze plekken spelen ze een grote rol.

Websites en hyperlinks

Elke link in HTML gebruikt een URI, in het href-attribuut. Ook afbeeldingen, scripts en stylesheets laadt een browser via een URI. Een webpagina is in feite een netwerk van URI's die naar elkaar wijzen.

API's

Bij een REST API heeft elke resource een eigen URI, zoals /klanten/42/bestellingen. De HTTP-methode bepaalt wat je met die resource doet: ophalen met GET, aanmaken met POST, aanpassen met PUT en verwijderen met DELETE. Een logische URI-structuur maakt een API veel makkelijker te begrijpen.

XML namespaces

In XML gebruik je een URI als naam voor een namespace. Zo lopen twee elementen met dezelfde naam niet door elkaar. SVG gebruikt bijvoorbeeld http://www.w3.org/2000/svg. Die URI hoeft niet naar een bestaande pagina te leiden. Hij dient alleen als unieke naam.

Linked data en het semantic web

In linked data krijgt alles een URI: personen, plaatsen, begrippen en de relaties ertussen. Dat gebeurt vaak in het RDF-formaat. Zo kunnen losse databases naar dezelfde dingen verwijzen. Wikidata werkt bijvoorbeeld op deze manier.

Apps en deep links

Apps gebruiken vaak een eigen scheme om direct naar een bepaald scherm te springen, zoals spotify: of whatsapp:. Dat heten deep links. Ook hier geldt gewoon de opbouw van een URI.

Korte geschiedenis van de URI

Het idee achter de URI komt van Tim Berners-Lee, de bedenker van het World Wide Web. Hij wilde één manier om alles op het web te benoemen. In zijn eerste voorstel stond de U nog voor universal. Tijdens het werk aan de standaard binnen de IETF werd dat uniform.

Daarna groeide de standaard in een paar stappen uit tot wat we nu gebruiken.

Met RFC 3986 werd URI de officiële hoofdterm. Browsers volgen daarnaast de WHATWG URL Standard. Die gebruikt juist overal het woord URL, omdat de meeste mensen dat woord kennen.

De URI als vast adres voor alles op het web

Een uniform resource identifier is de vaste manier om een resource te benoemen. Elke URI volgt dezelfde opbouw: scheme, authority, path, query en fragment. Een URL vertelt waar iets staat. Een URN geeft het alleen een naam. Allebei vallen ze onder de URI.

Wie met websites, API's of data werkt, heeft elke dag met URI's te maken. Snap je hoe ze in elkaar zitten, dan bouw je betere links en vind je fouten sneller. Een vergeten percent-encoding of een verkeerde relatieve link is dan zo opgelost.