{"id":89253,"date":"2020-07-21T01:42:24","date_gmt":"2020-07-20T23:42:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/krutye-uri-ne-izmenyayutsya"},"modified":"2020-07-21T01:42:24","modified_gmt":"2020-07-20T23:42:24","slug":"krutye-uri-ne-izmenyayutsya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/krutye-uri-ne-izmenyayutsya","title":{"rendered":"Toffe URI's veranderen niet","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

De auteur is sir Tim Berners-Lee, de uitvinder van URI, URL, HTTP, HTML en het World Wide Web, en de huidige directeur van het W3C. Het artikel is geschreven in 1998. <\/p>\n

Welke URI kan als 'cool' worden beschouwd?
\nEen die niet verandert.
\nHoe veranderen URI's?
\nURI's veranderen niet: mensen veranderen ze.<\/i> <\/p>\n

Ideaal gezien zouden mensen geen redenen moeten hebben om URI's te veranderen (of om documenten niet te onderhouden), maar in de praktijk zijn er miljoenen.<\/p>\n

In theorie bezit de nominale eigenaar van de domeinruimte daadwerkelijk de domeinnaamruimte en dus alle URI's daarin. Behalve insolvabiliteit, staat niets de eigenaar van de domeinnaam in de weg om deze naam te behouden. En in theorie is de URI-ruimte onder jouw domeinnaam volledig onder jouw controle, zodat je deze zo stabiel kunt maken als je wilt. In wezen is de enige goede reden voor een document om van internet te verdwijnen dat het bedrijf dat de domeinnaam bezat, failliet is gegaan of zich de kosten van het serveronderhoud niet meer kan veroorloven. Waarom zijn er dan zo veel dode links op internet? Voor een deel is het gewoon een gebrek aan vooruitziendheid. Hier zijn enkele redenen die je kunt horen:
\n<\/a><\/noindex><\/p>\n

We hebben de website gewoon opnieuw georganiseerd om deze beter te maken.<\/h4>\n

\nDenk je echt dat oude URI's niet meer kunnen werken? Als dat zo is, heb je ze heel slecht gekozen. Denk na over hoe de nieuwe na de volgende redesign bewaard blijven.<\/p>\n

We hebben zoveel materiaal dat we niet kunnen bijhouden wat verouderd, wat vertrouwelijk is en wat nog actueel is, en daarom dachten we dat het beter was om alles gewoon uit te schakelen.<\/h4>\n

\nIk kan alleen maar medelijden hebben. W3C heeft een periode doorgemaakt waarin we zorgvuldig archiefmateriaal moesten screenen op vertrouwelijkheid voordat we het openbaar maakten. Het besluit moet van tevoren goed doordacht zijn \u2014 zorg ervoor dat je met elk document een acceptabel lezerspubliek, de datum van creatie en idealiter de vervaldatum vastlegt. Bewaar deze metadata.<\/p>\n

We have found that we need to move the files\u2026<\/h4>\n

\nDit is een van de meest schrijnende rechtvaardigingen. Veel mensen weten niet dat webservers je in staat stellen om de verbinding tussen de URI van een object en de daadwerkelijke locatie ervan in het bestandssysteem te beheren. Stel je de URI-ruimte voor als een abstracte ruimte, perfect georganiseerd. Maak vervolgens een mapping naar de echte realiteit die je daadwerkelijk gebruikt om deze te implementeren. Geef dit vervolgens door aan de webserver. Je kunt zelfs een fragment van je server schrijven om alles correct te doen.<\/p>\n

John ondersteunt dit bestand niet meer, nu doet Jane dat.<\/p>\n

Stond de naam van John in de URI? Nee, het bestand lag gewoon in zijn directory? Dat is duidelijk.<\/p>\n

Eerder gebruikten we hiervoor een CGI-script, en nu gebruiken we een binaire toepassing.<\/h4>\n

\nThere is a crazy idea that pages created by scripts should be located in the \"cgibin\" or \"cgi\" area. This exposes the mechanism of how you run your web server. Change the mechanism (even while keeping the content), and oops \u2014 all your URIs change.<\/p>\n

Laten we bijvoorbeeld de Nationale Wetenschapsstichting (NSF) nemen:<\/p>\n

Online documenten van NSF<\/p>\n

http:\/\/www.nsf.gov\/cgi-bin\/pubsys\/browser\/odbrowse.pl<\/pre>\n
\nDe eerste pagina om documenten te bekijken zal over een paar jaar duidelijk niet hetzelfde blijven. cgi-bin<\/code>, oldbrowse<\/code> en pl<\/code>\u00a0\u2014 dit alles geeft fragmenten van informatie over hoe-we-het-nu-doen. Als je echter een pagina gebruikt om een document te zoeken, krijg je meteen ook een even slecht resultaat:<\/p>\n
Rapport van de werkgroep cryptografie en coderingstheorie<\/p>\n
http:\/\/www.nsf.gov\/cgi-bin\/getpub?nsf9814<\/pre>\n
\nvoor de indexpagina van het document, hoewel het html-document zelf er veel beter uitziet:<\/p>\n
http:\/\/www.nsf.gov\/pubs\/1998\/nsf9814\/nsf9814.htm<\/pre>\n
\nHier geeft de titel pubs\/1998 elke toekomstige archiefdienst een goede sleutel om te begrijpen dat het oude classificatieschema van documenten uit 1998 nog werkt. Hoewel in 2098 de documentnummers er misschien anders uitzien, kan ik me voorstellen dat deze URI nog steeds geldig zal zijn, en het zal NSF of een andere organisatie die het archief ondersteunt, niet in de weg staan.<\/p>\n
Ik dacht niet dat URL's permanent moesten zijn \u2014 er waren toch URN's.<\/h4>\n
\nWaarschijnlijk is dit een van de ergste bijwerkingen van de discussie over URN. Sommigen denken dat als gevolg van onderzoek naar een meer permanent naamruimte ze nonchalant kunnen omgaan met dode links, omdat \"URN dat allemaal zal oplossen\". Als je een van deze mensen bent, laat me je dan teleurstellen.<\/p>\n
De meeste URN-schema's die ik heb gezien, zien eruit als een autoriteitsidentificator, gevolgd door een datum en een string die je kiest, of gewoon een string die je kiest. Dit lijkt heel veel op een HTTP-URI. Met andere woorden, als je denkt dat jouw organisatie in staat zal zijn om langdurige URN's te cre\u00ebren, bewijs dat dan nu door ze te gebruiken voor je HTTP-URI's. In HTTP zelf is er niets dat je URI onbetrouwbaar maakt. Alleen jouw organisatie. Maak een database die de URN van het document koppelt aan de huidige bestandsnaam, en laat de webserver deze gebruiken voor het feitelijke ophalen van bestanden.<\/p>\n
Als je dit punt hebt bereikt, en als je geen tijd, geld en connecties hebt om enige software te ontwikkelen, kun je de volgende rechtvaardiging geven:<\/p>\n
We wilden het, maar we hebben gewoon niet de juiste tools.<\/h4>\n
\nDaar kun je mee medelijden hebben. Ik ben het er helemaal mee eens. Wat je moet doen, is de webserver in staat stellen om onmiddellijk een permanente URI te verwerken en het bestand terug te geven, waar het ook momenteel wordt opgeslagen in jouw huidige chaotische bestandssysteem. Je wilt alle URI's in een bestand opslaan als verificatie en de database voortdurend actueel houden. Je wilt de relaties tussen verschillende versies en vertalingen van hetzelfde document behouden, evenals een onafhankelijke controlewaarde opnemen om te zorgen voor bescherming tegen bestandscorruptie door een toevallige fout. En webservers worden gewoon niet standaard geleverd met deze functies. Wanneer je een nieuw document wilt maken, vraagt je editor om een URI in te voeren.<\/p>\n
Je hebt de mogelijkheid nodig om eigendom, toegang tot het document, archiveringsbeveiligingsniveau en andere zaken in de URI-ruimte te wijzigen zonder de URI te wijzigen.<\/p>\n
Het is allemaal te slecht. Maar we zullen het probleem oplossen. Bij W3C gebruiken we de functionaliteit van Jigedit (de Jigsaw-server voor editing), die versies bijhoudt, en we experimenteren met scripts voor documentcreatie. Als je tools, servers en clients ontwikkelt, let op dit probleem!<\/p>\n
Deze rechtvaardiging geldt ook voor veel W3C-pagina's, inclusief deze: dus doe wat ik zeg, niet wat ik doe.<\/p>\n
Waarom zou ik me daar druk om maken?<\/h1>\n
\nWanneer u de URI op uw server wijzigt, kunt u nooit volledig zeggen wie er naar de oude URI zal linken. Dit kunnen links zijn van gewone webpagina's. Bladwijzers naar uw pagina. De URI kan op de marges van een brief aan een vriend zijn gekrabbeld.<\/p>\n
Wanneer iemand op een link klikt en deze is verbroken, verliest diegene meestal het vertrouwen in de eigenaar van de server. Ze zijn ook teleurgesteld - zowel emotioneel als in werkelijkheid door de onmogelijkheid om hun doel te bereiken.<\/p>\n
Veel mensen klagen voortdurend over gebroken links, en ik hoop dat de schade duidelijk is. Ik hoop ook dat de reputatieschade voor de onderhoudsman van de server, waar het document verdwenen is, ook duidelijk is.<\/p>\n
Wat moet ik doen? Ontwerp een URI.<\/h1>\n
\nHet is de plicht van de webbeheerder om URI's te maken die over 2 jaar, over 20 jaar, over 200 jaar nog gebruikt kunnen worden. Hiervoor zijn doordachtheid, organisatie en doelgerichtheid nodig.<\/p>\n
URI's veranderen als er iets aan de informatie verandert. Het is erg belangrijk hoe je ze ontwerpt. (Wat, een URI ontwerpen? Moet ik een URI ontwerpen? Ja, daar moet je over nadenken). Ontwerpen betekent in wezen dat er geen informatie in de URI hoort te staan.<\/p>\n
De datum van creatie van het document - de datum waarop de URI wordt uitgegeven - is iets dat nooit zal veranderen. Het is zeer nuttig om verzoeken die het nieuwe systeem gebruiken te scheiden van diegene die het oude systeem gebruiken. Dit is een goed begin voor een URI. Als er een datum op het document staat, zelfs als het document in de toekomst actueel blijft, dan is dat een goed begin.<\/p>\n
De enige uitzondering is een pagina die opzettelijk de 'laatste' versie is, bijvoorbeeld voor een hele organisatie of een groot deel ervan.<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/latest\/<\/pre>\n
\nDit is de laatste column van Money Daily in het tijdschrift Money. De belangrijkste reden waarom deze URI geen datum nodig heeft, is dat er geen redenen zijn om de URI te behouden die het tijdschrift zal overleven. Het begrip Money Daily zal verdwijnen wanneer Money verdwijnt. Als je naar de inhoud wilt verwijzen, moet je er apart naar verwijzen in archieven:<\/p>\n
http:\/\/www.pathfinder.com\/money\/moneydaily\/1998\/981212.moneyonline.html<\/pre>\n
\n(Looks good. Assumes that \"money\" will mean the same throughout the existence of pathfinder.com. There is duplication of \"98\" and an unnecessary \".html\", but otherwise it looks like a strong URI.<\/p>\n
Wat aan de kant laten<\/h4>\n
\nAlles! Behalve de creatiedatum, door enige informatie in de URI te plaatsen, vraag je op de een of andere manier om problemen.<\/p>\n