Автор — сэр Тим Бернерс-Ли, изобретатель URI, URL, HTTP, HTML и Всемирной паутины, действующий глава W3C. Статья написана в 1998 году
Какой URI можно считать «крутым»?
Такой, который не изменяется.
Как изменяются URI?
URI не изменяются: их изменяют люди.
По идее, у людей нет никаких причин изменять URI (или прекращать поддерживать документы), но на практике их миллионы.
Теоретически, номинальный владелец пространства доменных имён действительно владеет пространством доменных имен и, следовательно, всеми URI в нём. Кроме неплатёжеспособности, ничто не мешает владельцу доменного имени сохранить это имя. И теоретически, пространство URI под вашим доменным именем полностью находится под вашим контролем, так что вы можете сделать его таким стабильным, как вам нравится. В значительной степени единственная веская причина для исчезновения документа из интернета заключается в том, что компания, которой принадлежало доменное имя, вышла из бизнеса или больше не может позволить себе поддерживать работу сервера. Тогда почему в мире так много пропавших ссылок? Отчасти это просто недостаток предусмотрительности. Вот некоторые причины, которые можно услышать:
Вам действительно кажется, что старые URI не могут больше работать? Если так, то вы выбрали их очень плохо. Подумайте о том, чтобы новые сохранились после следующего редизайна.
Могу только посочувствовать. W3C пережила период, когда нам приходилось тщательно просеивать архивные материалы на предмет конфиденциальности, прежде чем сделать их достоянием общественности. Решение должно быть продумано заранее — убедитесь, что вы фиксируете с каждым документом приемлемый круг читателей, дату создания и, в идеале, срок действия. Сохраните эти метаданные.
Это одно из самых жалких оправданий. Многие не знают, что веб-серверы позволяют вам управлять связью между URI объекта и фактическим его местонахождением в файловой системе. Представьте себе пространство URI как абстрактное пространство, идеально организованное. Затем сделайте отображение на любую реальность, которую вы на самом деле используете для её реализации. Затем сообщите об этом веб-серверу. Вы даже можете написать фрагмент своего сервера, чтобы сделать всё правильно.
Джон больше не поддерживает этот файл, теперь это делает Джейн.
Имя Джона было в URI? Нет, просто файл лежал в его директории? Ну понятно.
Существует сумасшедшая идея, что страницы, созданные скриптами, должны быть расположены в области "cgibin" или "cgi". Это раскрывает наружу механизм того, как вы запускаете свой веб-сервер. Меняете механизм (даже сохраняя контент), и упс — все ваши URI меняются.
Возьмём, к примеру, Национальный научный фонд (NSF):
Онлайн-документы NSF
Первая страница для начала просмотра документов явно не останется такой через несколько лет.
Доклад рабочей группы по криптологии и теории кодирования
для индексной страницы документа, хотя сам html-документ выглядит гораздо лучше:
Здесь заголовок pubs/1998 даст любому будущему архивному сервису хороший ключ к пониманию того, что действует старая схема классификации документов 1998 года. Хотя в 2098 году номера документов могут выглядеть иначе, но я могу себе представить, что этот URI всё ещё будет действителен, и он никак не помешает NSF или любой другой организации, которая будет поддерживать архив.
Вероятно, это один из худших побочных эффектов обсуждения URN. Некоторые думают, что из-за исследований о более постоянном пространстве имён они могут небрежно относиться к висячим ссылкам, поскольку «URN всё это исправят». Если вы один из этих людей, то позвольте вас разочаровать.
Большинство схем URN, которые я видел, выглядят как идентификатор авторитета, за которым следует либо дата и строка, которую вы выбираете, либо просто строка, которую вы выбираете. Это очень похоже на HTTP URI. Другими словами, если вы думаете, что ваша организация будет способна создавать долгоживущие URN, то докажите это сейчас, используя их для своих HTTP URI. В самом HTTP нет ничего, что делало бы ваш URI нестабильным. Только ваша организация. Создайте базу данных, которая сопоставляет URN документа с текущим именем файла, и позвольте веб-серверу использовать её для фактического извлечения файлов.
Если вы дошли до этого момента, то если у вас нет времени, денег и связей, чтобы разработать какое-то программное обеспечение, то вы можете заявить следующее оправдание:
А вот этому можно посочувствовать. Я полностью согласен. Что вам нужно сделать, так это заставить веб-сервер мгновенно обработать постоянный URI и вернуть файл, где бы он ни хранился в данный момент в вашей текущей сумасшедшей файловой системе. Вы хотите хранить все URI в файле в качестве проверки и постоянно поддерживать базу данных в соответствии с актуальностью. Вы хотите сохранить отношения между различными версиями и переводами одного и того же документа, а также сохранить независимую запись контрольной суммы, чтобы обеспечить защиту от повреждения файла случайной ошибкой. И веб-серверы просто не выходят из коробки с этими функциями. Когда вы хотите создать новый документ, ваш редактор просит задать URI.
Вам нужна возможность изменять владение, доступ к документу, уровень безопасности архивного уровня и прочее в пространстве URI без изменения URI.
Всё слишком плохо. Но мы исправим ситуацию. В W3C мы используем функциональность Jigedit (сервер Jigsaw для редактирования), которая отслеживает версии, и мы экспериментируем со скриптами создания документов. Если вы разрабатываете инструменты, серверы и клиенты, обратите внимание на эту проблему!
Это оправдание относится также ко многим страницам W3C, включая эту: так что делайте то, что я говорю, а не то, что я делаю.
Когда вы меняете URI на своём сервере, вы никогда не можете полностью сказать, у кого будут ссылки на старый URI. Это могут быть ссылки с обычных веб-страниц. Закладки на вашу страницу. URI мог быть нацарапан на полях письма к другу.
Когда кто-то переходит по ссылке и она сломана, он обычно теряет доверие к владельцу сервера. Он также разочарован — и эмоционально, и реально от невозможности достичь своей цели.
Много людей постоянно жалуются на битые ссылки, и я надеюсь, что ущерб очевиден. Надеюсь, что также очевиден репутационный ущерб мейнтейнеру сервера, где исчез документ.
Это обязанность веб-мастера — выделять URI, которые можно будет использовать через 2 года, через 20 лет, через 200 лет. Для этого нужны продуманность, организованность и целеустремленность.
URI меняются, если в них меняется какая-то информация. Очень важно, как вы их проектируете. (Что, дизайн URI? Мне нужно проектировать URI? Да, вы должны подумать об этом). Проектирование в основном означает отсутствие какой-либо информации в URI.
Дата создания документа — дата выдачи URI — то, что никогда не изменится. Она очень полезна для разделения запросов, которые используют новую систему, от тех, которые используют старую систему. С неё хорошо начинать URI. Если на документе проставлена какая-то дата, даже если документ будет актуален в будущем, то это хорошее начало.
Единственным исключением является страница, которая намеренно является «последней» версией, например, для всей организации или большой её части.
Это последняя колонка Money Daily в журнале Money. Основная причина, по которой в этом URI не нужна дата, заключается в том, что нет никаких причин для сохранения URI, который переживёт журнал. Понятие Money Daily исчезнет тогда, когда исчезнет Money. Если вы хотите сослаться на контент, следует сослаться на него отдельно в архивах:
(Выглядит хорошо. Предполагает, что "money" будут означать одно и то же на протяжении всего существования pathfinder.com. Есть дублирование "98" и ненужный ".html", но в остальном выглядит как сильный URI.
Всё! Кроме даты создания, помещая любую информацию в URI, вы так или иначе напрашиваетесь на неприятности.
Так что лучший пример с нашего сайта — это просто
… отчёт о протоколе заседания председателей 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). И не нужно помещать разные типы файлов в разные каталоги, на самом деле согласование содержимого не будет работать, если вы это сделаете.
Ссылки с расширениями всё ещё будут работать, но не позволят вашему серверу выбрать лучший из доступных в настоящее время и будущих форматов.
(На самом деле,
Конечно, если вы пишете собственный веб-сервер, то неплохо использовать базу данных для привязки постоянных идентификаторов к их текущей форме, хотя остерегайтесь неограниченного роста БД.
В течение 1999 года я отслеживал закрытие школ из-за снега по странице
— По состоянию на.
В настоящее время ничего не закрыто. Пожалуйста, возвращайтесь в случае погодных предупреждений.
Не может быть, такой же сильный шторм. Забавно, что дата отсутствует. Но если перейти на главную страницу сайта, там будет большая кнопка «Закрытые школы», которая ведёт на страницу
Может, они изменили систему получения списка — но им не нужно было менять URI.
С растущей зависимостью от интернета пришла умная мысль, что в приложения можно внедрять ссылки на сайт производителя. Этим часто пользовались и сильно злоупотребляли, но — нельзя менять URL. Буквально на днях я попробовал ссылку из клиента Microsoft Netmeeting 2/something в меню Help/Microsoft on the Web/Free stuff получил ошибку 404 — не найден ответ от сервера. Может, уже починили…
©1998 Tim BL
Историческое примечание: в конце 20-го века, когда это написано, «круто» было эпитетом одобрения, особенно среди молодёжи, указывающим на модность, качество или уместность. В спешке путь URI часто выбирали из «крутости», а не полезности или долговечности. Эта заметка — попытка перенаправить энергию, стоящую за поиском крутости.
Какой 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 Tim BL
Историческое примечание: в конце 20-го века, когда это написано, «круто» было эпитетом одобрения, особенно среди молодёжи, указывающим на модность, качество или уместность. В спешке путь URI часто выбирали из «крутости», а не полезности или долговечности. Эта заметка — попытка перенаправить энергию, стоящую за поиском крутости.
См. также:
