May-akda: Sir Tim Berners-Lee, imbentor ng mga URI, URL, HTTP, HTML at World Wide Web, at kasalukuyang pinuno ng W3C. Isinulat ang artikulo noong 1998

Anong URI ang itinuturing na "cool"?
Isa na hindi nagbabago.
Paano binago ang mga URI?
Hindi nagbabago ang mga URI: binabago sila ng mga tao.

Sa teorya, walang dahilan para baguhin ng mga tao ang mga URI (o ihinto ang pagsuporta sa mga dokumento), ngunit sa pagsasagawa mayroong milyun-milyon sa kanila.

Sa teorya, ang nominal na may-ari ng isang domain namespace ay aktwal na nagmamay-ari ng domain namespace at samakatuwid ang lahat ng mga URI sa loob nito. Bukod sa insolvency, walang pumipigil sa may-ari ng isang domain name na panatilihin ang pangalan. At sa teorya, ang puwang ng URI sa ilalim ng iyong domain name ay ganap na nasa ilalim ng iyong kontrol, kaya maaari mong gawin itong matatag hangga't gusto mo. Halos ang tanging magandang dahilan para mawala ang isang dokumento sa internet ay ang kumpanyang nagmamay-ari ng domain name ay nawala sa negosyo o hindi na kayang panatilihing tumatakbo ang server. Kung gayon bakit napakaraming nawawalang link sa mundo? Ang ilan sa mga ito ay isang kakulangan lamang ng pag-iisip. Narito ang ilang dahilan na maaari mong marinig:

Inayos lang namin ang site para mapaganda ito.

Sa tingin mo ba ay hindi na gagana ang mga lumang URI? Kung gayon, pinili mo ang mga ito nang hindi maganda. Pag-isipang panatilihin ang mga bago pagkatapos ng iyong susunod na muling pagdidisenyo.

Mayroon kaming napakaraming bagay na hindi namin masubaybayan kung ano ang luma na, kung ano ang kumpidensyal, at kung ano ang may kaugnayan pa rin, kaya naisip namin na pinakamahusay na i-off na lang ang lahat.

Makikisimpatya lang ako. Dumaan ang W3C sa isang panahon kung saan kinailangan naming maingat na suriing mabuti ang mga materyales sa archival para sa pagiging kumpidensyal bago isapubliko ang mga ito. Ang desisyon ay dapat pag-isipan nang maaga - siguraduhin na sa bawat dokumento ay itinatala mo ang katanggap-tanggap na mambabasa, petsa ng paglikha at, sa isip, petsa ng pag-expire. I-save ang metadata na ito.

Well, natuklasan namin na kailangan naming ilipat ang mga file...

Ito ay isa sa mga pinaka-kalunos-lunos na dahilan. Hindi alam ng maraming tao na pinapayagan ka ng mga web server na kontrolin ang kaugnayan sa pagitan ng URI ng isang bagay at ang aktwal na lokasyon nito sa file system. Isipin ang espasyo ng URI bilang abstract space, perpektong organisado. Pagkatapos ay gumawa ng pagmamapa sa anumang katotohanan na aktwal mong ginagamit upang mapagtanto ito. Pagkatapos ay iulat ito sa web server. Maaari mo ring isulat ang sarili mong snippet ng server para maayos ito.

Hindi na pinapanatili ni John ang file na ito, ginagawa na ngayon ni Jane.

Nasa URI ba ang pangalan ni John? Hindi, nasa direktoryo lang ba ang file? Well, okay.

Noong nakaraan, gumamit kami ng CGI script para dito, ngunit ngayon ay gumagamit kami ng binary program.

Mayroong isang nakatutuwang ideya na ang mga pahina na nilikha ng mga script ay dapat na matatagpuan sa "cgibin" o "cgi" na lugar. Inilalantad nito ang mga mekanika ng kung paano mo pinapatakbo ang iyong web server. Binago mo ang mekanismo (kahit habang nagse-save ng content), at oops - lahat ng URI mo ay nagbabago.

Kunin ang National Science Foundation (NSF) bilang halimbawa:

Mga Online na Dokumento ng NSF

http://www.nsf.gov/cgi-bin/pubsys/browser/odbrowse.pl

Ang unang pahina upang simulan ang pagtingin sa mga dokumento ay malinaw na hindi mananatiling pareho sa loob ng ilang taon. cgi-bin, oldbrowse и pl - ang lahat ng ito ay nagbibigay ng mga piraso ng impormasyon tungkol sa kung paano-namin-na-nagagawa-ngayon. Kung gagamitin mo ang pahina upang maghanap ng isang dokumento, ang unang resulta na makukuha mo ay parehong masama:

Ulat ng Working Group sa Cryptology at Coding Theory

http://www.nsf.gov/cgi-bin/getpub?nsf9814

para sa pahina ng index ng dokumento, kahit na ang html na dokumento mismo ay mukhang mas mahusay:

http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm

Dito, ang header ng pub/1998 ay magbibigay sa anumang serbisyo sa archival sa hinaharap ng magandang palatandaan na ang lumang 1998 na pamamaraan ng pag-uuri ng dokumento ay may bisa. Bagama't maaaring mag-iba ang hitsura ng mga numero ng dokumento noong 2098, maiisip ko na ang URI na ito ay magiging wasto pa rin at hindi makakasagabal sa NSF o anumang iba pang organisasyon na magpapapanatili sa archive.

Hindi ko naisip na ang mga URL ay kailangang maging paulit-ulit - may mga URN.

Ito ay marahil ang isa sa mga pinakamasamang epekto ng debate sa URN. Iniisip ng ilang tao na dahil sa pagsasaliksik sa isang mas permanenteng namespace, maaaring maging pabaya sila sa mga nakalawit na link dahil "Aayusin ng mga URN ang lahat ng iyon." Kung isa ka sa mga taong ito, hayaan mo akong biguin ka.

Karamihan sa mga scheme ng URN na nakita ko ay mukhang isang pagkakakilanlan ng awtoridad na sinusundan ng alinman sa isang petsa at isang string na iyong pipiliin, o isang string lamang na iyong pipiliin. Ito ay halos kapareho sa isang HTTP URI. Sa madaling salita, kung sa tingin mo ay makakagawa ang iyong organisasyon ng mga pangmatagalang URN, patunayan ito ngayon sa pamamagitan ng paggamit sa mga ito para sa iyong mga HTTP URI. Walang anuman sa HTTP mismo na ginagawang hindi matatag ang iyong URI. Tanging ang iyong organisasyon. Gumawa ng database na nagmamapa ng dokumentong URN sa kasalukuyang pangalan ng file, at hayaan ang web server na gamitin ito upang aktwal na makuha ang mga file.

Kung naabot mo na ang puntong ito, kung wala kang oras, pera at koneksyon upang bumuo ng ilang software, maaari mong sabihin ang sumusunod na dahilan:

Gusto namin, ngunit wala kaming tamang mga tool.

Ngunit maaari kang makiramay dito. Ako ay lubos na sumasang-ayon. Ang kailangan mong gawin ay pilitin ang web server na agad na i-parse ang patuloy na URI at ibalik ang file kung saan man ito kasalukuyang naka-imbak sa iyong kasalukuyang nakatutuwang file system. Gusto mong iimbak ang lahat ng URI sa isang file bilang isang tseke at panatilihing napapanahon ang database sa lahat ng oras. Gusto mong panatilihin ang ugnayan sa pagitan ng iba't ibang bersyon at pagsasalin ng parehong dokumento, at magpanatili din ng independiyenteng talaan ng checksum upang matiyak na ang file ay hindi nasira ng hindi sinasadyang error. At ang mga web server ay hindi lalabas sa kahon na may mga tampok na ito. Kapag gusto mong gumawa ng bagong dokumento, hihilingin sa iyo ng iyong editor na tumukoy ng URI.

Kailangan mong baguhin ang pagmamay-ari, pag-access sa dokumento, seguridad sa antas ng archive, atbp. sa espasyo ng URI nang hindi binabago ang URI.

Masyadong masama ang lahat. Pero itatama natin ang sitwasyon. Sa W3C, ginagamit namin ang functionality na Jigedit (Jigsaw editing server) na sumusubaybay sa mga bersyon, at nag-eeksperimento kami sa mga script ng paggawa ng dokumento. Kung bumuo ka ng mga tool, server, at kliyente, bigyang pansin ang problemang ito!

Nalalapat din ang palusot na ito sa maraming pahina ng W3C, kabilang ang isang ito: kaya gawin ang sinasabi ko, hindi ang ginagawa ko.

Bakit ako mag-aalaga?

Kapag binago mo ang URI sa iyong server, hindi mo ganap na masasabi kung sino ang magkakaroon ng mga link sa lumang URI. Ang mga ito ay maaaring mga link mula sa mga regular na web page. I-bookmark ang iyong pahina. Maaaring na-scrawl ang URI sa mga gilid ng isang liham sa isang kaibigan.

Kapag may sumunod sa isang link at nasira ito, kadalasang nawawalan sila ng tiwala sa may-ari ng server. Nabigo rin siya, kapwa emosyonal at pisikal, sa hindi niya maabot ang kanyang layunin.

Maraming tao ang nagrereklamo tungkol sa mga sirang link sa lahat ng oras, at umaasa ako na ang pinsala ay halata. Sana ay halata din ang pinsala sa reputasyon sa maintainer ng server kung saan nawala ang dokumento.

Kaya ano ang dapat kong gawin? Disenyo ng URI

Responsibilidad ng webmaster na maglaan ng mga URI na magagamit sa loob ng 2 taon, sa 20 taon, sa 200 taon. Nangangailangan ito ng pag-iisip, organisasyon at determinasyon.

Magbabago ang mga URI kung magbabago ang anumang impormasyon sa mga ito. Kung paano mo idisenyo ang mga ito ay napakahalaga. (Ano, disenyo ng URI? Kailangan ko bang idisenyo ang URI? Oo, dapat mong isipin iyon). Ang disenyo ay karaniwang nangangahulugan ng pag-iiwan ng anumang impormasyon sa URI.

Ang petsa kung kailan ginawa ang dokumento - ang petsa na ibinigay ang URI - ay isang bagay na hinding-hindi magbabago. Ito ay lubhang kapaki-pakinabang para sa paghihiwalay ng mga query na gumagamit ng bagong system mula sa mga gumagamit ng lumang system. Ito ay isang magandang lugar upang magsimula sa isang URI. Kung ang isang dokumento ay napetsahan, kahit na ang dokumento ay may kaugnayan sa hinaharap, kung gayon ito ay isang magandang simula.

Ang tanging pagbubukod ay isang page na sadyang "pinakabagong" bersyon, halimbawa para sa buong organisasyon o malaking bahagi nito.

http://www.pathfinder.com/money/moneydaily/latest/

Ito ang pinakabagong Money Daily column sa Money magazine. Ang pangunahing dahilan kung bakit hindi na kailangan ng petsa sa URI na ito ay walang dahilan para iimbak ang URI na lalabas sa log. Mawawala ang konsepto ng Money Daily kapag nawala ang Pera. Kung nais mong mag-link sa nilalaman, dapat mong i-link ito nang hiwalay sa archive:

http://www.pathfinder.com/money/moneydaily/1998/981212.moneyonline.html

(Mukhang maganda. Ipinapalagay na ang "pera" ay magkakaroon ng parehong bagay sa buong buhay ng pathfinder.com. May duplicate na "98" at isang hindi kinakailangang ".html", ngunit sa kabilang banda ay mukhang isang malakas na URI.

Ano ang dapat itabi

Lahat! Bukod sa petsa ng paglikha, ang paglalagay ng anumang impormasyon sa URI ay humihingi ng problema sa isang paraan o iba pa.

Pangalan ng may-akda. Maaaring magbago ang pagiging may-akda kapag naging available ang mga bagong bersyon. Ang mga tao ay umaalis sa mga organisasyon at ipinapasa ang mga bagay sa iba.
Bagay. Ito ay napakahirap. Palagi itong maganda sa una, ngunit nakakagulat na mabilis itong nagbabago. Magsasalita pa ako tungkol dito sa ibaba.
Katayuan. Ang mga direktoryo tulad ng "luma", "draft" at iba pa, hindi banggitin ang "pinakabago" at "cool", ay lilitaw sa lahat ng mga file system. Ang mga dokumento ay nagbabago ng katayuan - kung hindi, walang saysay na gumawa ng mga draft. Ang pinakabagong bersyon ng isang dokumento ay nangangailangan ng patuloy na pagkakakilanlan, anuman ang katayuan nito. Panatilihin ang katayuan sa labas ng pangalan.
Pag-access. Sa W3C, hinati namin ang site sa mga seksyon para sa mga empleyado, miyembro, at publiko. Ito ay pakinggan, ngunit siyempre, ang mga dokumento ay nagsisimula bilang mga ideya ng koponan mula sa mga kawani, ay tinatalakay sa mga miyembro, at pagkatapos ay naging kaalaman ng publiko. Nakakahiya talaga kung sa tuwing bubuksan ang isang dokumento para sa mas malawak na talakayan, lahat ng lumang link dito ay sira! Ngayon lumipat kami sa isang simpleng code ng petsa.
Extension ng file. Isang napakakaraniwang pangyayari. "cgi", kahit na ang ".html" ay magbabago sa hinaharap. Maaaring hindi ka gumagamit ng HTML para sa pahinang ito sa loob ng 20 taon, ngunit dapat pa ring gumana ang mga link ngayon dito. Ang mga kanonikal na link sa W3C site ay hindi gumagamit ng extension (kung paano ito ginawa).
Mga mekanismo ng software. Sa URI, hanapin ang "cgi", "exec" at iba pang termino na sumisigaw ng "tingnan kung anong software ang ginagamit namin." May nais bang gugulin ang kanilang buong buhay sa pagsusulat ng mga script ng Perl CGI? Hindi? Pagkatapos ay alisin ang .pl extension. Basahin ang manual ng server kung paano ito gagawin.
Pangalan ng disk. Halika na! Pero nakita ko na ito.

Kaya ang pinakamahusay na halimbawa mula sa aming site ay simple

http://www.w3.org/1998/12/01/chairs

... ulat sa mga minuto ng pulong ng W3C Chairs.

Mga paksa at pag-uuri ayon sa paksa

Iisa-isahin ko pa ang tungkol sa panganib na ito, dahil isa ito sa mga bagay na pinakamahirap iwasan. Karaniwan, napupunta ang mga paksa sa mga URI kapag ikinategorya mo ang iyong mga dokumento ayon sa gawaing ginagawa nila. Ngunit ang pagkasira na ito ay magbabago sa paglipas ng panahon. Magbabago ang mga pangalan ng mga lugar. Sa W3C gusto naming baguhin ang MarkUP sa Markup at pagkatapos ay sa HTML upang ipakita ang aktwal na nilalaman ng seksyon. Bilang karagdagan, madalas mayroong flat namespace. Sa loob ng 100 taon, sigurado ka bang wala kang gugustuhing muling gamitin? Sa aming maikling buhay, gusto na naming gamitin muli ang "Kasaysayan" at "Style Sheets" halimbawa.

Ito ay isang mapang-akit na paraan upang ayusin ang isang website—at isang tunay na mapang-akit na paraan upang ayusin ang anuman, kabilang ang buong Web. Ito ay isang mahusay na medium-term na solusyon ngunit may malubhang pagkukulang sa pangmatagalan.

Bahagi ng dahilan ay nakasalalay sa pilosopiya ng kahulugan. Ang bawat termino sa isang wika ay isang potensyal na target para sa clustering, at ang bawat tao ay maaaring may iba't ibang ideya kung ano ang ibig sabihin nito. Dahil ang mga ugnayan sa pagitan ng mga entity ay mas katulad ng web kaysa sa isang puno, kahit na ang mga sumasang-ayon sa web ay maaaring pumili ng ibang representasyon ng puno. Ito ang aking (madalas na paulit-ulit) pangkalahatang mga obserbasyon tungkol sa mga panganib ng hierarchical classification bilang isang pangkalahatang solusyon.

Sa katunayan, kapag gumamit ka ng pangalan ng paksa sa isang URI, ibinibigay mo ang iyong sarili sa ilang uri ng pag-uuri. Marahil sa hinaharap ay mas gusto mo ang ibang opsyon. Ang URI ay magiging madaling kapitan sa paglabag.

Ang dahilan ng paggamit ng isang subject area bilang bahagi ng isang URI ay ang responsibilidad para sa mga subsection ng URI space ay karaniwang itinatalaga, at pagkatapos ay kailangan mo ang pangalan ng organisasyonal na katawan - departamento, grupo, o anupaman - na responsable para sa subspace na iyon. Ito ay isang URI na nagbubuklod sa isang istraktura ng organisasyon. Ito ay karaniwang ligtas lamang kung ang karagdagang (kaliwa) URI ay protektado ng isang petsa: 1998/pics ay maaaring mangahulugan sa iyong server na "kung ano ang ibig sabihin namin noong 1998 na may mga larawan" sa halip na "kung ano ang ginawa namin noong 1998 sa tinatawag naming mga larawan ngayon."

Huwag kalimutan ang domain name

Tandaan na nalalapat ito hindi lamang sa path sa URI, kundi pati na rin sa pangalan ng server. Kung mayroon kang hiwalay na mga server para sa iba't ibang mga bagay, tandaan na ang dibisyong ito ay imposibleng baguhin nang hindi sinisira ang marami, maraming mga link. Ang ilang mga klasikong pagkakamali sa "tingnan ang software na ginagamit namin ngayon" ay ang mga domain name na "cgi.pathfinder.com", "secure", "lists.w3.org". Ang mga ito ay idinisenyo upang gawing mas madali ang pangangasiwa ng server. Hindi alintana kung ang isang domain ay kumakatawan sa isang dibisyon sa iyong kumpanya, isang katayuan ng dokumento, isang antas ng pag-access, o isang antas ng seguridad, maging napaka-ingat bago gumamit ng higit sa isang pangalan ng domain para sa maraming uri ng dokumento. Tandaan na maaari mong itago ang maramihang mga web server sa loob ng isang nakikitang web server gamit ang pag-redirect at pag-proxy.

Oh, at isipin din ang tungkol sa iyong domain name. Hindi mo nais na tukuyin bilang soap.com pagkatapos mong magpalit ng mga linya ng produkto at huminto sa paggawa ng sabon (Paumanhin sa sinumang nagmamay-ari ng soap.com sa ngayon).

Konklusyon

Ang pagpapanatili ng isang URI sa loob ng 2, 20, 200, o kahit na 2000 taon ay malinaw na hindi kasingdali ng tila. Gayunpaman, sa buong Internet, ang mga webmaster ay gumagawa ng mga desisyon na nagpapahirap sa gawaing ito para sa kanilang sarili sa hinaharap. Kadalasan ito ay dahil gumagamit sila ng mga tool na ang trabaho ay upang ipakita ang pinakamahusay na site lamang sa sandaling ito - at walang sinuman ang nagsuri kung ano ang mangyayari sa mga link kapag nagbago ang lahat. Gayunpaman, ang punto dito ay marami, maraming bagay ang maaaring magbago, at ang iyong mga URI ay maaari at dapat na manatiling pareho. Ito ay posible lamang kapag iniisip mo kung paano mo nilikha ang mga ito.

Tingnan din:

Tira ni Jakob Nielsen sa parehong paksa

Mga karagdagan

Paano tanggalin ang mga extension ng file...

...mula sa isang URI sa kasalukuyang file-based na web server?

Kung gumagamit ka ng Apache, halimbawa, maaari mo itong i-configure upang makipag-ayos ng nilalaman. I-save ang extension ng file (hal. .png) sa isang file (hal. mydog.png), ngunit maaari kang mag-link sa isang mapagkukunan ng web nang wala ito. Pagkatapos ay sinusuri ng Apache ang direktoryo para sa lahat ng mga file na may ganoong pangalan at anumang extension, at maaaring piliin ang pinakamahusay mula sa hanay (halimbawa, GIF at PNG). At hindi na kailangang maglagay ng iba't ibang uri ng mga file sa iba't ibang direktoryo, sa katunayan ay hindi gagana ang pagtutugma ng nilalaman kung gagawin mo iyon.

I-set up ang iyong server para makipag-ayos ng content
Palaging mag-link sa mga URI nang walang extension

Ang mga link na may mga extension ay gagana pa rin, ngunit pipigilan ang iyong server sa pagpili ng pinakamahusay na format na magagamit sa kasalukuyan at sa hinaharap.

(Sa katunayan, mydog, mydog.png и mydog.gif — wastong mga mapagkukunan ng web, mydog ay isang unibersal na mapagkukunan ng uri ng nilalaman, at mydog.png и mydog.gif — mga mapagkukunan ng isang tiyak na uri ng nilalaman).

Siyempre, kung nagsusulat ka ng iyong sariling web server, magandang ideya na gumamit ng database upang itali ang mga persistent identifier sa kanilang kasalukuyang anyo, bagama't mag-ingat sa walang limitasyong paglago ng database.

The Board of Shame - Kuwento 1: Channel 7

Noong 1999, nasubaybayan ko ang mga pagsasara ng paaralan dahil sa snow sa pahina http://www.whdh.com/stormforce/closings.shtml. Huwag hintayin na lumabas ang impormasyon sa ibaba ng screen ng TV! Na-link ko ito mula sa aking home page. Dumating ang unang malaking snow storm noong 2000 at tiningnan ko ang pahina. Nakasulat doon:,

- Bilang ng.
Walang nakasara sa kasalukuyan. Mangyaring bumalik sa kaso ng mga babala ng panahon.

Hindi ito maaaring maging isang malakas na bagyo. Nakakatuwa na kulang ang date. Ngunit kung pupunta ka sa pangunahing pahina ng site, magkakaroon ng malaking button na "Mga Sarado na Paaralan", na humahantong sa pahina http://www.whdh.com/stormforce/ na may mahabang listahan ng mga saradong paaralan.

Marahil ay binago nila ang sistema para sa pagkuha ng listahan - ngunit hindi nila kailangang baguhin ang URI.

Board of Shame - Kuwento 2: Microsoft Netmeeting

Sa lumalaking pag-asa sa Internet, isang matalinong ideya ang dumating na ang mga link sa website ng gumawa ay maaaring i-embed sa mga application. Ito ay ginamit at inabuso nang marami, ngunit hindi mo mababago ang URL. Noong isang araw lang sinubukan ko ang isang link mula sa Microsoft Netmeeting 2/something client sa Help/Microsoft on the Web/Free stuff menu at nakatanggap ako ng 404 error - walang nahanap na tugon mula sa server. Siguro naayos na nila...

Tala sa kasaysayan: Noong huling bahagi ng ika-20 siglo, nang isulat ito, ang "cool" ay isang epithet ng pag-apruba, lalo na sa mga kabataan, na nagpapahiwatig ng pagiging fashionable, kalidad, o pagiging angkop. Sa pagmamadali, ang URI path ay madalas na pinili para sa "cool" kaysa sa pagiging kapaki-pakinabang o tibay. Ang post na ito ay isang pagtatangka na i-redirect ang enerhiya sa likod ng paghahanap ng cool.

Pinagmulan: www.habr.com

Ang mga cool na URI ay hindi nagbabago