المؤلف: السير تيم بيرنرز لي، مخترع عناوين 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. يعتقد بعض الأشخاص أنه بسبب البحث في مساحة اسم أكثر ديمومة، قد يكونون مهملين بشأن الروابط المتدلية لأن "URNs ستصلح كل ذلك". إذا كنت واحداً من هؤلاء الأشخاص، فدعني أخيب ظنك.

تبدو معظم مخططات URN التي رأيتها كمعرف مرجعي متبوعًا إما بتاريخ وسلسلة تحددها، أو مجرد سلسلة تحددها. وهذا مشابه جدًا لـ HTTP URI. بمعنى آخر، إذا كنت تعتقد أن مؤسستك ستكون قادرة على إنشاء عناوين URN طويلة الأمد، فقم بإثبات ذلك الآن باستخدامها لعناوين URL HTTP الخاصة بك. لا يوجد شيء في HTTP نفسه يجعل URI الخاص بك غير مستقر. مؤسستك فقط. قم بإنشاء قاعدة بيانات تقوم بتعيين URN للمستند إلى اسم الملف الحالي، واسمح لخادم الويب باستخدامه لاسترداد الملفات فعليًا.

إذا وصلت إلى هذه النقطة، ولم يكن لديك الوقت والمال والاتصالات لتطوير بعض البرامج، فيمكنك تقديم العذر التالي:

أردنا ذلك، لكن ليس لدينا الأدوات الصحيحة.

ولكن يمكنك التعاطف مع هذا. أنا أتفق تماما. ما عليك القيام به هو إجبار خادم الويب على تحليل URI المستمر على الفور وإعادة الملف أينما تم تخزينه حاليًا على نظام الملفات المجنون الحالي. تريد تخزين جميع عناوين URI في ملف كفحص والحفاظ على تحديث قاعدة البيانات في جميع الأوقات. أنت تريد الحفاظ على العلاقة بين الإصدارات والترجمات المختلفة لنفس المستند، وكذلك الاحتفاظ بسجل اختباري مستقل لضمان عدم تلف الملف بسبب خطأ غير مقصود. وخوادم الويب ببساطة لا تأتي مع هذه الميزات. عندما تريد إنشاء مستند جديد، يطلب منك المحرر تحديد URI.

يجب أن تكون قادرًا على تغيير الملكية، والوصول إلى المستندات، والأمان على مستوى الأرشيف، وما إلى ذلك في مساحة URI دون تغيير URI.

كل شيء سيء للغاية. لكننا سوف نقوم بتصحيح الوضع. في W3C، نستخدم وظيفة Jigedit (خادم تحرير Jigsaw) التي تتتبع الإصدارات، ونقوم بتجربة البرامج النصية لإنشاء المستندات. إذا قمت بتطوير الأدوات والخوادم والعملاء، انتبه لهذه المشكلة!

ينطبق هذا العذر أيضًا على العديد من صفحات W3C، بما في ذلك هذه الصفحة: لذا افعل كما أقول، وليس كما أفعل.

لماذا يجب أن أهتم؟

عندما تقوم بتغيير URI على الخادم الخاص بك، لا يمكنك أبدًا معرفة من سيكون لديه روابط إلى URI القديم. يمكن أن تكون هذه روابط من صفحات الويب العادية. قم بوضع إشارة مرجعية على صفحتك. ربما تم كتابة عنوان URI على هوامش رسالة إلى صديق.

عندما يتبع شخص ما رابطًا ويكون معطلاً، فإنه عادةً ما يفقد الثقة في مالك الخادم. كما أنه يشعر بالإحباط عاطفياً وجسدياً لعدم قدرته على تحقيق هدفه.

الكثير من الناس يشكون من الروابط المعطلة طوال الوقت، وأتمنى أن يكون الضرر واضحاً. آمل أن يكون الضرر الذي لحق بسمعة مشرف الخادم حيث اختفى المستند واضحًا أيضًا.

اذا ماذا يجب أن أفعل؟ تصميم URI

تقع على عاتق مشرف الموقع مسؤولية تخصيص عناوين URI التي يمكن استخدامها خلال عامين، أو خلال 2 عامًا، أو خلال 20 عام. وهذا يتطلب التفكير والتنظيم والتصميم.

تتغير عناوين URI في حالة تغير أي معلومات فيها. كيف تصممها مهم جدا. (ماذا، تصميم URI؟ هل أحتاج إلى تصميم URI؟ نعم، يجب أن تفكر في ذلك). التصميم يعني في الأساس ترك أي معلومات في URI.

إن تاريخ إنشاء المستند - تاريخ إصدار URI - هو شيء لن يتغير أبدًا. وهو مفيد جدًا لفصل الاستعلامات التي تستخدم النظام الجديد عن تلك التي تستخدم النظام القديم. يعد هذا مكانًا جيدًا للبدء باستخدام URI. إذا كانت الوثيقة مؤرخة، حتى لو كانت الوثيقة ذات صلة في المستقبل، فهذه بداية جيدة.

الاستثناء الوحيد هو الصفحة التي تكون عن عمد الإصدار "الأحدث"، على سبيل المثال للمؤسسة بأكملها أو لجزء كبير منها.

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

هذا هو أحدث عمود Money Daily في مجلة Money. السبب الرئيسي لعدم الحاجة إلى تاريخ في URI هذا هو أنه لا يوجد سبب لتخزين URI الذي سيستمر بعد انتهاء السجل. سيختفي مفهوم Money Daily عندما يختفي Money. إذا كنت ترغب في الارتباط بالمحتوى، فيجب عليك الارتباط به بشكل منفصل في الأرشيف:

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

(يبدو جيدًا. بافتراض أن كلمة "المال" ستعني نفس الشيء طوال عمر موقع pathfinder.com. هناك نسخة مكررة من "98" و".html" غير ضروري، ولكن بخلاف ذلك يبدو وكأنه عنوان URI قوي.

ماذا نترك جانبا

الجميع! وبصرف النظر عن تاريخ الإنشاء، فإن وضع أي معلومات في URI يسبب مشكلة بطريقة أو بأخرى.

اسم المؤلف. قد يتغير التأليف مع توفر إصدارات جديدة. يترك الناس المنظمات ويمررون الأشياء للآخرين.
موضوع. انه صعب جدا. تبدو دائمًا جيدة في البداية، ولكنها تتغير بسرعة مدهشة. سأتحدث أكثر عن هذا أدناه.
حالة. تظهر الدلائل مثل "القديم" و"المسودة" وما إلى ذلك، ناهيك عن "الأحدث" و"الرائع"، في جميع أنظمة الملفات. تتغير حالة المستندات - وإلا فلن يكون هناك أي فائدة في إنشاء المسودات. يحتاج أحدث إصدار من المستند إلى معرف ثابت، بغض النظر عن حالته. أبقِ الحالة خارج الاسم.
وصول. في W3C، قمنا بتقسيم الموقع إلى أقسام للموظفين والأعضاء والجمهور. يبدو هذا جيدًا، ولكن بالطبع، تبدأ المستندات كأفكار جماعية من الموظفين، وتتم مناقشتها مع الأعضاء، ثم تصبح معرفة عامة. سيكون من العار حقًا أن تنقطع كل الروابط القديمة المرتبطة بها في كل مرة يتم فيها فتح مستند لمناقشة أوسع! ننتقل الآن إلى رمز تاريخ بسيط.
امتداد الملف. أمر شائع جدًا. "cgi"، وحتى ".html" سوف يتغير في المستقبل. ربما لن تستخدم HTML لهذه الصفحة منذ 20 عامًا، ولكن من المفترض أن تظل الروابط الحالية إليها تعمل. لا تستخدم الروابط الأساسية الموجودة على موقع W3C الامتداد (كيف يتم ذلك).
آليات البرمجيات. في URI، ابحث عن "cgi" و"exec" والمصطلحات الأخرى التي تصرخ "انظر إلى البرنامج الذي نستخدمه". هل يرغب أي شخص في قضاء حياته بأكملها في كتابة نصوص Perl CGI؟ لا؟ ثم قم بإزالة الامتداد .pl. اقرأ دليل الخادم حول كيفية القيام بذلك.
اسم القرص. تعال! لكني رأيت هذا.

لذا فإن أفضل مثال من موقعنا هو ببساطة

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

... تقرير عن محضر اجتماع رؤساء W3C.

المواضيع والتصنيف حسب الموضوع

وسوف أتناول المزيد من التفاصيل حول هذا الخطر، لأنه أحد الأشياء التي يصعب تجنبها. عادةً ما تنتهي المواضيع في عناوين URI عندما تقوم بتصنيف مستنداتك حسب العمل الذي تقوم به. لكن هذا الانهيار سوف يتغير مع مرور الوقت. وسوف تتغير أسماء المناطق. في W3C أردنا تغيير MarkUP إلى Markup ثم إلى HTML ليعكس المحتوى الفعلي للقسم. بالإضافة إلى ذلك، غالبًا ما تكون هناك مساحة اسم مسطحة. بعد 100 عام، هل أنت متأكد من أنك لن ترغب في إعادة استخدام أي شيء؟ في حياتنا القصيرة، أردنا بالفعل إعادة استخدام "التاريخ" و"أوراق الأنماط" على سبيل المثال.

إنها طريقة مغرية لتنظيم موقع ويب، وطريقة مغرية حقًا لتنظيم أي شيء، بما في ذلك الويب بأكمله. وهذا حل عظيم على المدى المتوسط، لكنه ينطوي على عيوب خطيرة على المدى الطويل.

جزء من السبب يكمن في فلسفة المعنى. يعد كل مصطلح في اللغة هدفًا محتملاً للتكتل، وقد يكون لدى كل شخص فكرة مختلفة عما يعنيه ذلك المصطلح. نظرًا لأن العلاقات بين الكيانات تشبه شبكة الويب أكثر من كونها شجرة، فحتى أولئك الذين يتفقون مع الويب قد يختارون تمثيلًا مختلفًا للشجرة. هذه هي ملاحظاتي العامة (المتكررة كثيرًا) حول مخاطر التصنيف الهرمي كحل عام.

في الواقع، عند استخدام اسم موضوع في 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 في خادم الويب الحالي القائم على الملف؟

إذا كنت تستخدم Apache، على سبيل المثال، فيمكنك تكوينه للتفاوض على المحتوى. احفظ امتداد الملف (مثل .png) في ملف (مثل .png) mydog.png)، ولكن يمكنك الارتباط بمورد ويب بدونه. يقوم Apache بعد ذلك بالتحقق من الدليل بحثًا عن جميع الملفات التي تحمل هذا الاسم وبأي امتداد، ويمكنه اختيار أفضل ملف من المجموعة (على سبيل المثال، 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.

مجلس العار - القصة 2: Microsoft Netmeeting

مع الاعتماد المتزايد على الإنترنت، جاءت فكرة ذكية مفادها أنه يمكن تضمين الروابط إلى موقع الشركة المصنعة في التطبيقات. لقد تم استخدام هذا وإساءة استخدامه كثيرًا، لكن لا يمكنك تغيير عنوان URL. لقد قمت منذ بضعة أيام فقط بتجربة ارتباط من عميل Microsoft Netmeeting 2/something في قائمة التعليمات/Microsoft في قائمة الويب/الأشياء المجانية وتلقيت خطأ 404 - لم يتم العثور على أي استجابة من الخادم. ربما تم إصلاحه بالفعل ...

ملاحظة تاريخية: في أواخر القرن العشرين، عندما تمت كتابة هذا، كانت كلمة "رائع" بمثابة صفة للاستحسان، خاصة بين الشباب، للإشارة إلى الموضة أو الجودة أو الملاءمة. على عجل، غالبًا ما يتم اختيار مسار URI من أجل "الروعة" بدلاً من الفائدة أو المتانة. هذا المنشور هو محاولة لإعادة توجيه الطاقة وراء البحث عن الجمال.

المصدر: www.habr.com

عناوين URI الرائعة لا تتغير