Автор - сер Тім Бернерс-Лі, винахідник 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, то доведіть це зараз, використовуючи їх для своїх HTTP URI. У самому 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/
Це остання колонка 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" зміняться у майбутньому. Можливо, через 20 років ви не будете використовувати HTML для цієї сторінки, але сьогоднішні посилання ще повинні працювати. Канонічні посилання на сайті 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 році під pics, а не те, що в 1998 році ми зробили з тим, що тепер називаємо pics».
Не забудьте доменне ім'я
Пам'ятайте, що це стосується не тільки шляху в URI, але й імені сервера. Якщо у вас є окремі сервери для різних речей, пам'ятайте, що цей поділ буде неможливо змінити, не знищивши багато посилань. Деякі класичні помилки типу "погляньте, яке програмне забезпечення ми використовуємо сьогодні" - доменні імена "cgi.pathfinder.com", "secure", "lists.w3.org". Вони створені для полегшення адміністрування серверів. Незалежно від того, чи домен представляє якийсь підрозділ у вашій компанії, статус документа, рівень доступу або рівень безпеки, будьте дуже, дуже обережні, перш ніж використовувати більше одного доменного імені для декількох типів документів. Пам'ятайте, що ви можете приховати безліч веб-серверів всередині одного видимого веб-сервера, використовуючи перенаправлення та проксіювання.
Так, і ще подумайте про своє доменне ім'я. Ви ж не хочете, щоб на вас посилалися як на мило.ком після того, як ви зміните продуктову лінійку і перестанете виробляти мило (Перепрошую у того, хто володіє 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: Channel 7
Протягом 1999 року я відстежував закриття шкіл через сніг по сторінці http://www.whdh.com/stormforce/closings.shtml. Не чекати, коли інформація з'явиться внизу екрана телевізора! Я поставив на неї посилання зі своєї домашньої сторінки. Настає перший великий сніговий шторм 2000 року, і я перевіряю сторінку. Там написано:,
- За станом на.
Нині нічого не закрито. Будь ласка, повертайтеся у разі погодних попереджень.
Не може бути такий же сильний шторм. Смішно, що дата відсутня. Але якщо перейти на головну сторінку сайту, буде велика кнопка «Закриті школи», яка веде на сторінку http://www.whdh.com/stormforce/ з довгим списком закритих шкіл.
Можливо, вони змінили систему отримання списку, але їм не потрібно було змінювати URI.
Дошка ганьби - Історія 2: Microsoft Netmeeting
З зростаючою залежністю від інтернету прийшла розумна думка, що додатки можна впроваджувати посилання на сайт виробника. Цим часто користувалися і сильно зловживали, але не можна міняти URL. Буквально днями спробував посилання з клієнта Microsoft Netmeeting 2/something у меню Help/Microsoft on the Web/Free stuff отримав помилку 404 — не знайдено відповідь від сервера. Може, вже полагодили…
© 1998
Історична примітка: наприкінці 20-го століття, коли це написано, «круто» було епітетом схвалення, особливо серед молоді, що вказує на модність, якість чи доречність. Поспіхом шлях URI часто вибирали з «крутості», а не корисності чи довговічності. Ця нотатка - спроба перенаправити енергію, яка стоїть за пошуком крутості.
Джерело: habr.com