نویسنده: سر تیم برنرز لی، مخترع URI ها، URL ها، HTTP، HTML و شبکه جهانی وب، و رئیس فعلی W3C. مقاله نوشته شده در سال 1998

کدام URI "باحال" در نظر گرفته می شود؟
یکی که تغییر نمی کند.
URI ها چگونه تغییر می کنند؟
URI ها تغییر نمی کنند: مردم آنها را تغییر می دهند.

در تئوری، هیچ دلیلی وجود ندارد که مردم URI ها را تغییر دهند (یا اسناد پشتیبانی را متوقف کنند)، اما در عمل میلیون ها مورد وجود دارد.

در تئوری، مالک اسمی فضای نام دامنه در واقع مالک فضای نام دامنه و در نتیجه تمام URI های درون آن است. به غیر از ورشکستگی، هیچ چیز مانع از حفظ نام مالک یک دامنه نمی شود. و از نظر تئوری، فضای URI تحت نام دامنه شما کاملاً تحت کنترل شما است، بنابراین می توانید آن را تا آنجا که دوست دارید پایدار کنید. تقریباً تنها دلیل خوب برای ناپدید شدن یک سند از اینترنت این است که شرکت صاحب نام دامنه از کار افتاده است یا دیگر نمی تواند سرور را در حال اجرا نگه دارد. پس چرا این همه حلقه گمشده در جهان وجود دارد؟ برخی از اینها صرفاً عدم تدبیر است. در اینجا دلایلی وجود دارد که ممکن است بشنوید:

ما فقط سایت را دوباره سازماندهی کردیم تا بهتر شود.

آیا واقعا فکر می کنید که URI های قدیمی دیگر نمی توانند کار کنند؟ اگر چنین است، پس شما آنها را بسیار ضعیف انتخاب کرده اید. برای طراحی مجدد بعدی، موارد جدید را نگه دارید.

ما چیزهای زیادی داریم که نمی‌توانیم موارد قدیمی، محرمانه و هنوز مرتبط را ردیابی کنیم، بنابراین فکر کردیم بهتر است همه آن‌ها را خاموش کنیم.

من فقط می توانم همدردی کنم. W3C دوره‌ای را پشت سر گذاشت که ما مجبور شدیم قبل از انتشار عمومی، مطالب آرشیوی را برای محرمانه بودن به دقت بررسی کنیم. تصمیم باید از قبل اندیشیده شود - مطمئن شوید که با هر سند خوانندگان قابل قبول، تاریخ ایجاد و، در حالت ایده آل، تاریخ انقضا را ثبت می کنید. این ابرداده را ذخیره کنید.

خب، ما متوجه شدیم که باید فایل ها را جابجا کنیم...

این یکی از رقت انگیزترین بهانه هاست. بسیاری از مردم نمی دانند که وب سرورها به شما اجازه می دهند تا رابطه بین URI یک شی و مکان واقعی آن را در سیستم فایل کنترل کنید. فضای URI را به عنوان یک فضای انتزاعی، کاملا سازمان یافته در نظر بگیرید. سپس یک نقشه برداری از واقعیتی که واقعاً برای درک آن استفاده می کنید، انجام دهید. سپس این را به وب سرور گزارش دهید. شما حتی می توانید قطعه سرور خود را بنویسید تا درست شود.

جان دیگر این فایل را نگهداری نمی کند، جین اکنون این کار را انجام می دهد.

آیا نام جان در URI بود؟ نه، آیا فایل فقط در دایرکتوری او بود؟ بسیار خوب.

قبلا از یک اسکریپت CGI برای این کار استفاده می کردیم، اما اکنون از یک برنامه باینری استفاده می کنیم.

یک ایده دیوانه کننده وجود دارد که صفحات ایجاد شده توسط اسکریپت ها باید در ناحیه "cgibin" یا "cgi" قرار گیرند. این مکانیزم نحوه اجرای وب سرور خود را نشان می دهد. شما مکانیسم را تغییر می دهید (حتی در حین ذخیره محتوا)، و اوه - همه URI های شما تغییر می کنند.

به عنوان مثال بنیاد ملی علوم (NSF) را در نظر بگیرید:

اسناد آنلاین NSF

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

اولین صفحه برای شروع مشاهده اسناد به وضوح تا چند سال دیگر ثابت نخواهد ماند. cgi-bin, oldbrowse и pl - همه اینها اطلاعاتی در مورد نحوه انجام این کار در حال حاضر به ما می دهد. اگر از صفحه برای جستجوی یک سند استفاده می کنید، اولین نتیجه ای که به دست می آورید به همان اندازه بد است:

گزارش کارگروه رمز شناسی و نظریه کدگذاری

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

برای صفحه فهرست سند، اگرچه خود سند html بسیار بهتر به نظر می رسد:

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

در اینجا هدر pubs/1998 به هر سرویس آرشیوی آینده سرنخ خوبی می دهد که طرح طبقه بندی اسناد قدیمی 1998 در حال اجرا است. اگرچه ممکن است شماره های اسناد در سال 2098 متفاوت به نظر برسند، من تصور می کنم که این URI همچنان معتبر است و با NSF یا هر سازمان دیگری که بایگانی را حفظ می کند تداخلی نخواهد داشت.

من فکر نمی کردم URL ها باید ثابت باشند - URN وجود داشت.

این احتمالا یکی از بدترین عوارض جانبی بحث URN است. برخی از مردم فکر می کنند که به دلیل تحقیق در مورد فضای نام دائمی تر، ممکن است در مورد پیوندهای آویزان بی توجه باشند زیرا "URN ها همه اینها را برطرف می کنند." اگر شما یکی از این افراد هستید، پس اجازه دهید شما را ناامید کنم.

اکثر طرح‌های URN که من دیده‌ام شبیه یک شناسه اعتبار هستند که با تاریخ و رشته‌ای که انتخاب می‌کنید یا فقط رشته‌ای که انتخاب می‌کنید به دنبال آن می‌آیند. این بسیار شبیه به یک HTTP URI است. به عبارت دیگر، اگر فکر می‌کنید سازمان شما قادر به ایجاد URN با عمر طولانی است، اکنون با استفاده از آن‌ها برای URI های HTTP خود آن را ثابت کنید. هیچ چیزی در خود HTTP وجود ندارد که URI شما را ناپایدار کند. فقط سازمان شما پایگاه داده ای ایجاد کنید که URN سند را به نام فایل فعلی نگاشت کند و به وب سرور اجازه دهید از آن برای بازیابی فایل ها استفاده کند.

اگر به این نقطه رسیده اید، اگر زمان، پول و اتصالات لازم برای توسعه برخی نرم افزارها را ندارید، می توانید بهانه زیر را بیان کنید:

ما می خواستیم، اما فقط ابزار مناسب نداریم.

اما شما می توانید با این همدردی کنید. کاملا موافقم کاری که باید انجام دهید این است که وب سرور را مجبور کنید تا فوراً URI پایدار را تجزیه کند و فایل را در هر کجا که در حال حاضر در سیستم فایل دیوانه فعلی شما ذخیره شده است، برگرداند. شما می خواهید همه URI ها را در یک فایل به عنوان چک ذخیره کنید و پایگاه داده را همیشه به روز نگه دارید. شما می‌خواهید رابطه بین نسخه‌های مختلف و ترجمه‌های یک سند را حفظ کنید، و همچنین یک رکورد جمع‌بندی مستقل برای اطمینان از خراب نشدن فایل توسط یک خطای تصادفی حفظ کنید. و وب سرورها به سادگی با این ویژگی ها از جعبه خارج نمی شوند. هنگامی که می خواهید یک سند جدید ایجاد کنید، ویرایشگر شما از شما می خواهد که یک URI را مشخص کنید.

شما باید بتوانید مالکیت، دسترسی به اسناد، امنیت سطح بایگانی و غیره را در فضای URI بدون تغییر URI تغییر دهید.

همه چیز خیلی بد است. اما ما وضعیت را اصلاح خواهیم کرد. در W3C، ما از عملکرد Jigedit (سرور ویرایش Jigsaw) استفاده می‌کنیم که نسخه‌ها را ردیابی می‌کند، و اسکریپت‌های تولید سند را آزمایش می‌کنیم. اگر ابزار، سرور و کلاینت توسعه می دهید، به این موضوع توجه کنید!

این بهانه در مورد بسیاری از صفحات W3C نیز صدق می کند، از جمله این: پس همانطور که من می گویم انجام دهید، نه آنطور که من انجام می دهم.

چرا باید اهمیت بدهم؟

وقتی URI سرور خود را تغییر می دهید، هرگز نمی توانید به طور کامل بگویید چه کسی به URI قدیمی پیوند دارد. اینها می توانند پیوندهایی از صفحات وب معمولی باشند. صفحه خود را نشانه گذاری کنید. URI ممکن است در حاشیه نامه ای به یک دوست خط خورده باشد.

هنگامی که شخصی پیوندی را دنبال می کند و آن را خراب می کند، معمولاً اعتماد خود را به صاحب سرور از دست می دهد. او همچنین از نرسیدن به هدف خود چه از نظر روحی و چه از نظر جسمی ناامید است.

بسیاری از مردم همیشه از لینک های شکسته شکایت می کنند و امیدوارم آسیب آن آشکار باشد. امیدوارم آسیب شهرت به نگهدارنده سروری که سند ناپدید شده نیز آشکار باشد.

پس من باید چه کار کنم؟ طراحی URI

این وظیفه مدیر وب سایت است که URI هایی را که می توانند در 2 سال، در 20 سال، در 200 سال استفاده شوند، اختصاص دهد. این امر مستلزم تفکر، سازماندهی و عزم است.

URI ها در صورت تغییر هر گونه اطلاعات در آنها تغییر می کنند. نحوه طراحی آنها بسیار مهم است. (چه، طراحی URI؟ آیا من نیاز به طراحی URI دارم؟ بله، شما باید در مورد آن فکر کنید). طراحی اساساً به معنای کنار گذاشتن هرگونه اطلاعات در URI است.

تاریخ ایجاد سند - تاریخی که URI صادر شد - چیزی است که هرگز تغییر نخواهد کرد. برای جدا کردن پرس و جوهایی که از سیستم جدید استفاده می کنند از آنهایی که از سیستم قدیمی استفاده می کنند بسیار مفید است. این مکان خوبی برای شروع با URI است. اگر یک سند دارای تاریخ باشد، حتی اگر سند در آینده مرتبط باشد، این شروع خوبی است.

تنها استثنا صفحه ای است که عمدا "آخرین" نسخه است، به عنوان مثال برای کل سازمان یا بخش بزرگی از آن.

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

این آخرین ستون مانی دیلی در مجله مانی است. دلیل اصلی عدم نیاز به تاریخ در این URI این است که هیچ دلیلی برای ذخیره کردن URI وجود ندارد که عمر طولانی‌تری از ثبت داشته باشد. مفهوم مانی دیلی با ناپدید شدن پول ناپدید می شود. اگر می خواهید به محتوا پیوند دهید، باید به طور جداگانه در آرشیو به آن پیوند دهید:

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

(به نظر خوب می رسد. فرض می کنیم که "پول" در طول عمر pathfinder.com به همین معنا خواهد بود. یک "98" تکراری و یک ".html" غیرضروری وجود دارد، اما در غیر این صورت یک URI قوی به نظر می رسد.

چه چیزی را کنار بگذاریم

همه! جدا از تاریخ ایجاد، قرار دادن هر گونه اطلاعات در URI به هر طریقی مشکل ایجاد می کند.

نام نویسنده. ممکن است با در دسترس قرار گرفتن نسخه های جدید، نویسندگی تغییر کند. مردم سازمان ها را ترک می کنند و چیزها را به دیگران منتقل می کنند.
چیز. خیلی سخت است. در ابتدا همیشه خوب به نظر می رسد، اما به سرعت تغییر می کند. در زیر بیشتر در این مورد صحبت خواهم کرد.
وضعیت. دایرکتوری هایی مانند "قدیمی"، "پیش نویس" و غیره، نه به ذکر "آخرین" و "باحال"، در همه سیستم های فایل ظاهر می شوند. اسناد تغییر وضعیت می دهند - در غیر این صورت هیچ فایده ای برای ایجاد پیش نویس وجود نخواهد داشت. آخرین نسخه یک سند، صرف نظر از وضعیت آن، به یک شناسه ثابت نیاز دارد. وضعیت را خارج از نام نگه دارید.
دسترسی. در W3C، ما سایت را به بخش هایی برای کارمندان، اعضا و عموم تقسیم کرده ایم. این خوب به نظر می رسد، اما البته، اسناد به عنوان ایده های تیمی از کارکنان شروع می شود، با اعضا مورد بحث قرار می گیرد و سپس به دانش عمومی تبدیل می شود. واقعا شرم آور است اگر هر بار که سندی برای بحث گسترده تر باز می شود، تمام لینک های قدیمی آن شکسته می شود! اکنون به سراغ یک کد تاریخ ساده می رویم.
فرمت فایل. یک پدیده بسیار رایج. "cgi"، حتی ".html" در آینده تغییر خواهد کرد. ممکن است در 20 سال گذشته از HTML برای این صفحه استفاده نکنید، اما پیوندهای امروزی به آن همچنان باید کار کنند. پیوندهای متعارف در سایت W3C از پسوند استفاده نمی کنند (چگونه انجام می شود).
مکانیزم های نرم افزاری. در URI به دنبال «cgi»، «exec» و دیگر عباراتی بگردید که فریاد می زنند «نگاه کن از چه نرم افزاری استفاده می کنیم». آیا کسی می خواهد تمام زندگی خود را صرف نوشتن اسکریپت های Perl CGI کند؟ نه؟ سپس پسوند pl را حذف کنید. راهنمای سرور در مورد نحوه انجام این کار را بخوانید.
نام دیسک بیا دیگه! اما من این را دیده ام

بنابراین بهترین مثال از سایت ما به سادگی است

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

... گزارش صورتجلسه روسای W3C.

موضوعات و طبقه بندی بر اساس موضوع

من به جزئیات بیشتری در مورد این خطر خواهم پرداخت، زیرا یکی از مواردی است که اجتناب از آن بسیار دشوار است. به طور معمول، زمانی که اسناد خود را بر اساس کارهایی که انجام می‌دهند دسته‌بندی می‌کنید، موضوعات به URI ختم می‌شوند. اما این شکست به مرور زمان تغییر خواهد کرد. نام مناطق تغییر خواهد کرد. در W3C می‌خواستیم MarkUP را به Markup و سپس به HTML تغییر دهیم تا محتوای واقعی بخش را منعکس کنیم. علاوه بر این، اغلب یک فضای نام مسطح وجود دارد. در 100 سال، آیا مطمئن هستید که نمی خواهید از چیزی دوباره استفاده کنید؟ در عمر کوتاه خود ما قبلاً می خواستیم برای مثال از "History" و "Style Sheets" دوباره استفاده کنیم.

این یک راه وسوسه انگیز برای سازماندهی یک وب سایت است - و یک روش واقعا وسوسه انگیز برای سازماندهی هر چیزی، از جمله کل وب. این یک راه حل میان مدت عالی است اما در دراز مدت دارای کاستی های جدی است.

بخشی از دلیل در فلسفه معنا نهفته است. هر اصطلاح در یک زبان یک هدف بالقوه برای خوشه بندی است و هر فردی ممکن است تصور متفاوتی از معنای آن داشته باشد. از آنجا که روابط بین موجودات بیشتر شبیه یک وب است تا یک درخت، حتی کسانی که با وب موافق هستند ممکن است نمایش متفاوتی از درخت را انتخاب کنند. اینها مشاهدات کلی من (اغلب مکرر) در مورد خطرات طبقه بندی سلسله مراتبی به عنوان یک راه حل کلی است.

در واقع، وقتی از نام موضوعی در یک URI استفاده می کنید، خود را متعهد به نوعی طبقه بندی می کنید. شاید در آینده گزینه دیگری را ترجیح دهید. سپس URI مستعد نقض خواهد شد.

دلیل استفاده از یک حوزه موضوعی به عنوان بخشی از یک URI این است که مسئولیت بخش‌های فرعی فضای URI معمولاً محول می‌شود و سپس شما به نام بدن سازمانی - بخش، گروه یا هر چیز دیگری - نیاز دارید که مسئولیت آن زیرفضا را بر عهده دارد. این یک URI الزام آور به یک ساختار سازمانی است. معمولاً فقط در صورتی ایمن است که URI بعدی (سمت چپ) با یک تاریخ محافظت شود: 1998/pics ممکن است برای سرور شما به معنای "آنچه در سال 1998 با عکس ها منظور ما بود" باشد نه "آنچه در سال 1998 با آنچه اکنون عکس می نامیم انجام دادیم."

نام دامنه را فراموش نکنید

به یاد داشته باشید که این نه تنها در مورد مسیر در URI، بلکه در مورد نام سرور نیز صدق می کند. اگر سرورهای جداگانه ای برای چیزهای مختلف دارید، به یاد داشته باشید که تغییر این تقسیم بندی بدون از بین بردن بسیاری از لینک ها غیرممکن خواهد بود. برخی از اشتباهات کلاسیک "نگاهی به نرم افزاری که امروز استفاده می کنیم" نام های دامنه "cgi.pathfinder.com"، "secure"، "lists.w3.org" هستند. آنها برای تسهیل مدیریت سرور طراحی شده اند. صرف نظر از اینکه یک دامنه نشان دهنده یک بخش در شرکت شما، وضعیت سند، سطح دسترسی یا سطح امنیتی است، قبل از استفاده از بیش از یک نام دامنه برای چندین نوع سند بسیار بسیار مراقب باشید. به یاد داشته باشید که می توانید چندین وب سرور را در داخل یک وب سرور قابل مشاهده با استفاده از تغییر مسیر و پروکسی پنهان کنید.

اوه، و همچنین در مورد نام دامنه خود فکر کنید. پس از اینکه خطوط تولید را تغییر دادید و ساخت صابون را متوقف کردید، نمی خواهید به عنوان soap.com معرفی شوید (با عرض پوزش برای هر کسی که soap.com در حال حاضر دارد).

نتیجه

واضح است که حفظ یک URI برای 2، 20، 200 یا حتی 2000 سال آنقدرها هم که به نظر می رسد آسان نیست. با این حال، در سرتاسر اینترنت، وب‌مسترها تصمیماتی می‌گیرند که این کار را در آینده برای خودشان واقعاً دشوار می‌کند. اغلب این به این دلیل است که آنها از ابزارهایی استفاده می کنند که وظیفه آنها ارائه بهترین سایت در لحظه است - و هیچ کس ارزیابی نکرده است که وقتی همه چیز تغییر کند چه اتفاقی برای پیوندها می افتد. با این حال، نکته اینجاست که بسیاری از چیزها می توانند تغییر کنند و URI های شما می توانند و باید ثابت بمانند. این تنها زمانی امکان پذیر است که به نحوه ایجاد آنها فکر کنید.

همچنین ببینید:

طنز یاکوب نیلسن در همین موضوع

افزوده

نحوه حذف پسوند فایل ...

... از یک URI در سرور وب مبتنی بر فایل فعلی؟

به عنوان مثال، اگر از آپاچی استفاده می کنید، می توانید آن را برای مذاکره با محتوا پیکربندی کنید. پسوند فایل (به عنوان مثال .png) را در یک فایل (مثلاً mydog.png، اما می توانید بدون آن به یک منبع وب پیوند دهید. سپس آپاچی دایرکتوری را برای همه فایل‌های با آن نام و هر پسوندی بررسی می‌کند و می‌تواند بهترین را از مجموعه (مثلا GIF و PNG) انتخاب کند. و نیازی به قرار دادن انواع مختلف فایل ها در دایرکتوری های مختلف نیست، در واقع اگر این کار را انجام دهید تطبیق محتوا کار نخواهد کرد.

سرور خود را برای مذاکره در مورد محتوا تنظیم کنید
همیشه بدون پسوند به URI ها پیوند دهید

پیوندهای دارای پسوند همچنان کار خواهند کرد، اما سرور شما را از انتخاب بهترین قالب موجود در حال حاضر و در آینده باز می‌دارد.

(در حقیقت، mydog, mydog.png и mydog.gif - منابع معتبر وب، mydog یک منبع از نوع محتوای جهانی است و mydog.png и mydog.gif - منابع یک نوع محتوای خاص).

البته، اگر در حال نوشتن وب سرور خود هستید، ایده خوبی است که از یک پایگاه داده برای اتصال شناسه های ثابت به شکل فعلی خود استفاده کنید، اگرچه مراقب رشد نامحدود پایگاه داده باشید.

هیئت شرم - داستان 1: کانال 7

در طول سال 1999، تعطیلی مدارس به دلیل برف را در صفحه پیگیری کردم http://www.whdh.com/stormforce/closings.shtml. منتظر ظاهر شدن اطلاعات در پایین صفحه تلویزیون نباشید! من از صفحه اصلی به آن لینک دادم. اولین طوفان بزرگ سال 2000 از راه می رسد و صفحه را چک می کنم. در آنجا نوشته شده است:

- از
در حال حاضر هیچ چیز بسته نیست. لطفا در صورت هشدار آب و هوا مراجعه کنید.

نمی تواند چنین طوفانی قوی باشد. خنده دار است که تاریخ گم شده است. اما اگر به صفحه اصلی سایت بروید، یک دکمه بزرگ "مدارس بسته" وجود دارد که به صفحه منتهی می شود. http://www.whdh.com/stormforce/ با لیست بلندبالایی از مدارس تعطیل شده

شاید آنها سیستم را برای دریافت لیست تغییر دادند - اما نیازی به تغییر URI نداشتند.

Board of Shame - Story 2: Microsoft Netmeeting

با افزایش وابستگی به اینترنت، ایده هوشمندانه ای مطرح شد که پیوندهایی به وب سایت سازنده می تواند در برنامه ها تعبیه شود. این مورد استفاده و سوء استفاده زیادی شده است، اما شما نمی توانید URL را تغییر دهید. همین روز قبل پیوندی از Microsoft Netmeeting 2/something در منوی Help/Microsoft on the Web/Free stuff امتحان کردم و یک خطای 404 دریافت کردم - هیچ پاسخی از سرور پیدا نشد. شاید قبلا درست شده...

یادداشت تاریخی: در اواخر قرن بیستم، زمانی که این نوشته می‌شد، «باحال» به عنوان یک لقب تأییدیه، به‌ویژه در میان جوانان، نشان‌دهنده شیک بودن، کیفیت یا مناسب بودن بود. با عجله، مسیر URI اغلب برای "خنک بودن" به جای مفید بودن یا دوام انتخاب می شد. این پست تلاشی برای هدایت مجدد انرژی پشت جستجوی جالب است.

منبع: www.habr.com

URI های جالب تغییر نمی کنند