Автор — сэр Тим Бернерс-Ли, изобретатель URI, URL, HTTP, HTML и Всемирной паутины, действующий глава W3C. Статья написана в 1998 году

איזה URI נחשב "מגניב"?
כזה שלא משתנה.
כיצד משנים URIs?
URIs לא משתנים: אנשים משנים אותם.

בתיאוריה, אין סיבה שאנשים ישנו URIs (או יפסיקו מסמכים תומכים), אבל בפועל יש מיליונים כאלה.

בתיאוריה, הבעלים הנומינלי של מרחב שמות דומיין הוא הבעלים של מרחב שמות הדומיין ולכן כל ה-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. יש אנשים שחושבים שבגלל המחקר על מרחב שמות קבוע יותר, הם עלולים להיות לא זהירים לגבי השתלשלות קישורים כי "כתובות URL יתקנו את כל זה." אם אתה אחד מהאנשים האלה, אז תן לי לאכזב אותך.

רוב ערכי ה-URN שראיתי נראות כמו מזהה סמכות ואחריו תאריך ומחרוזת שתבחר, או סתם מחרוזת שתבחר. זה דומה מאוד ל-HTTP URI. במילים אחרות, אם אתה חושב שהארגון שלך יהיה מסוגל ליצור URN ארוכי חיים, הוכח זאת כעת על ידי שימוש בהם עבור URIs HTTP שלך. אין שום דבר ב-HTTP עצמו שהופך את ה-URI שלך ללא יציב. רק הארגון שלך. צור מסד נתונים שממפה את URN המסמך לשם הקובץ הנוכחי, ואפשר לשרת האינטרנט להשתמש בו כדי לאחזר את הקבצים בפועל.

אם הגעתם לנקודה הזו, אם אין לכם זמן, כסף וקשרים לפתח תוכנה כלשהי, אז אתם יכולים לציין את התירוץ הבא:

Мы хотели, но у нас просто нет нужных инструментов.

אבל אתה יכול להזדהות עם זה. אני מסכים לחלוטין. מה שאתה צריך לעשות הוא לאלץ את שרת האינטרנט לנתח באופן מיידי את ה-URI הקבוע ולהחזיר את הקובץ בכל מקום שבו הוא מאוחסן כעת במערכת הקבצים המטורפת הנוכחית שלך. אתה רוצה לאחסן את כל ה-URI בקובץ כמחאה ולשמור את מסד הנתונים מעודכן בכל עת. אתה רוצה לשמר את הקשר בין גרסאות ותרגומים שונים של אותו מסמך, וגם לשמור על רשומת בדיקה עצמאית כדי להבטיח שהקובץ לא פגום על ידי שגיאה מקרית. ושרתי אינטרנט פשוט לא יוצאים מהקופסה עם התכונות האלה. כאשר אתה רוצה ליצור מסמך חדש, העורך שלך מבקש ממך לציין URI.

אתה צריך להיות מסוגל לשנות בעלות, גישה למסמכים, אבטחה ברמת הארכיון וכו' במרחב URI מבלי לשנות את URI.

הכל חבל. אבל נתקן את המצב. ב-W3C, אנו משתמשים בפונקציונליות Jigedit (שרת עריכה של Jigsaw) העוקבת אחר גרסאות, ואנחנו מתנסים עם סקריפטים ליצירת מסמכים. אם אתם מפתחים כלים, שרתים ולקוחות, שימו לב לנושא הזה!

תירוץ זה חל גם על דפי W3C רבים, כולל זה: אז תעשה מה שאני אומר, לא כמוני.

למה שיהיה אכפת לי?

כאשר אתה משנה את ה-URI בשרת שלך, לעולם לא תוכל לדעת לחלוטין למי יהיו קישורים ל-URI הישן. אלה יכולים להיות קישורים מדפי אינטרנט רגילים. סמן את הדף שלך בסימניות. ייתכן שה-URI היה משורבט בשולי מכתב לחבר.

כאשר מישהו עוקב אחר קישור והוא נשבר, הוא בדרך כלל מאבד את האמון בבעל השרת. הוא גם מתוסכל, הן רגשית והן פיזית, מכך שהוא לא מצליח להשיג את מטרתו.

הרבה אנשים מתלוננים על קישורים שבורים כל הזמן, ואני מקווה שהנזק ברור. אני מקווה שגם הנזק המוניטין למתחזק השרת שבו נעלם המסמך ברור.

אז מה עלי לעשות? עיצוב URI

באחריות מנהל האתר להקצות URIs שניתן להשתמש בהם בעוד שנתיים, בעוד 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

(Выглядит хорошо. Предполагает, что "money" будут означать одно и то же на протяжении всего существования 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/תמונות עשוי להיות אומר לשרת שלך "למה שהתכוונו ב-1998 עם תמונות" ולא "מה שב-1998 עשינו עם מה שאנחנו מכנים עכשיו תמונות."

אל תשכח את שם הדומיין

זכור שזה חל לא רק על הנתיב ב-URI, אלא גם על שם השרת. אם יש לך שרתים נפרדים לדברים שונים, זכור שאי אפשר יהיה לשנות את החלוקה הזו מבלי להרוס הרבה מאוד קישורים. כמה טעויות קלאסיות של "הסתכל על התוכנה שבה אנו משתמשים היום" הן שמות דומיין "cgi.pathfinder.com", "מאבטח", "lists.w3.org". הם נועדו להקל על ניהול השרת. לא משנה אם דומיין מייצג חטיבה בחברה שלך, סטטוס של מסמך, רמת גישה או רמת אבטחה, היזהר מאוד מאוד לפני השימוש ביותר משם דומיין אחד עבור סוגי מסמכים מרובים. זכור שאתה יכול להסתיר שרתי אינטרנט מרובים בתוך שרת אינטרנט גלוי אחד על ידי שימוש בניתוב מחדש ובפרוקסי.

אה, ותחשוב גם על שם הדומיין שלך. אתה לא רוצה שיתייחסו אליו כ-soap.com לאחר שתשנה קו מוצרים ותפסיק לייצר סבון (סליחה למי שבבעלותו soap.com כרגע).

מסקנה

שמירה על URI למשך 2, 20, 200 או אפילו 2000 שנים היא כמובן לא קלה כמו שזה נראה. עם זאת, בכל רחבי האינטרנט, מנהלי אתרים מקבלים החלטות שמקשות על עצמם את המשימה הזו בעתיד. לא פעם זה בגלל שהם משתמשים בכלים שתפקידם להציג את האתר הטוב ביותר רק כרגע – ואף אחד לא העריך מה יקרה לקישורים כשהכל ישתנה. עם זאת, הנקודה כאן היא שהרבה מאוד דברים יכולים להשתנות, ו-URI שלך יכול וצריך להישאר זהה. זה אפשרי רק כאשר אתה חושב על איך אתה יוצר אותם.

ראה גם:

• הטיריד של יעקב נילסן באותו נושא

תוספות

כיצד להסיר סיומות קבצים...

…из URI в текущем веб-сервере на основе файлов?

אם אתה משתמש ב- Apache, למשל, תוכל להגדיר אותו לנהל משא ומתן על תוכן. שמור את סיומת הקובץ (למשל .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.

Board of Shame - סיפור 2: Microsoft Netmeeting

עם התלות הגוברת באינטרנט, הגיע רעיון חכם שאפשר להטמיע קישורים לאתר היצרן באפליקציות. נעשה בו שימוש רב ונעשה בו שימוש לרעה, אך אינך יכול לשנות את כתובת האתר. רק לפני כמה ימים ניסיתי קישור מלקוח Microsoft Netmeeting 2/משהו בתפריט Help/Microsoft on the Web/Free stuff וקיבלתי שגיאה 404 - לא נמצאה תגובה מהשרת. אולי כבר תיקנו את זה...

© 1998 טים BL

הערה היסטורית: בסוף המאה ה-20, כשזה נכתב, "מגניב" היה כינוי לאישור, במיוחד בקרב צעירים, המעיד על אופנתיות, איכות או התאמה. בחיפזון, נתיב ה-URI נבחר לעתים קרובות בגלל "קרירות" ולא שימושיות או עמידות. הפוסט הזה הוא ניסיון לנתב מחדש את האנרגיה מאחורי החיפוש אחר מגניב.

מקור: www.habr.com