Предоставление дружественных URL для веб-сайта в сравнении с реалиями идентификаторов базы данных.

24

У нас есть база данных ресурсов, будь то продукты, сообщения в блогах или что-то в этом роде. Нам нужно разработать схему URL для их решения для общедоступного веб-сайта.

Вот два примера, которые привязаны к идентификатору базы данных:

Вот пример, который дружелюбен:

http://en.wikipedia.org/wiki/LED_circuit

(Небольшое представление о моей жизни там просмотра)

Мне нравятся дружественные URL-адреса, поскольку у вас есть представление о том, что находится в конце URL-адреса, когда вы наводите указатель мыши или видите его в электронном письме или документе. Это лучше для SEO, или раньше.

Что происходит, когда документ или продукт переименовывается? Или потому что это изменилось (Wiki может не измениться, но наши ресурсы могли бы) или из-за опечатки, верно? Наши ресурсы очень технические, длинные слова и ошибки.

Также у нас есть идентификатор базы данных, который является числом. Давайте посмотрим на идею для адреса видео с использованием притворного проката магазина:

http://vidsyeah.com/video/sliding-doors/287171

Идентификатор очевиден и используется при поиске БД. Хорошо.

Бит раздвижных дверей не является уникальным и только генерируется из заголовка видео, его можно проверить по GET, поэтому, если скользящие двери были введены и не соответствуют тому, что на самом деле в документе 287171, они отвечают 404.

Или, может быть, это можно игнорировать, позволяя людям сунуть туда все, что им нравится, если кому-то когда-нибудь захочется. Так что этот URL также будет работать:

http://vidsyeah.com/video/anything-at_all/287171

Проблема с проверкой дружественной части, как уже упоминалось, является проблемой переименования или исправления опечаток. Если имя изменилось, и в нашем домене это происходит, мы не хотим ломать существующие URL-адреса, поэтому мы должны:

Только не проверяйте дружескую часть.
Проверьте, но добавьте «историю» дружественных частей в запись базы данных, чтобы все предыдущие идентификаторы по-прежнему работали!

Ваши мысли и идеи приветствуются.

Люк

— Люк Пуплетт
источник

11

даже на этом самом сайте используется комбинация http://programmers.stackexchange.com/questions/255684/providing-friendly-urls-for-a-website-vs-realities-of-database-ids(с использованием непроверенной версии в свете изменений заголовка, также более короткая ссылка «поделиться» - это просто id: http://programmers.stackexchange.com/q/255684/25768(и идентификатор пользователя для отслеживания значка)

— ratchet freak

11

Если у вас есть уникальный идентификатор в вашем URL, я не понимаю, зачем вам вообще проверять часть слизня. Используйте его для внешнего вида и игнорируйте его для поиска.

— Торстен Мюллер

Если кто-то из вас захочет дать правильный ответ, я проголосую, чтобы вы получили очки. Я позволю голосам войти и наградить ответ большинству проголосовавших через пару дней.

— Люк Пуплетт

1

programmers.stackexchange.com/questions/231483/…

— комнат

3

Никогда раньше не знал термин «слизняк». Должно быть, я был под камнем. Geddit?

— Люк Пуплетт

6

Хранение идентификатора в URL-адресе является наиболее перспективным методом, и, как вы продемонстрировали, URL-адреса все еще могут выглядеть относительно хорошо.

Другим вариантом, используемым несколькими проектами, является сохранение истории ранее использованных слагов. Когда заголовок изменяется, вы обновляете слаг и, если кто-то пытается найти устаревший слаг, ищите в списке старых слагов. Таким образом, старые слагы могут быть повторно использованы для нового контента (или не в зависимости от вашей реализации).

Wordpress сделал это, как и гем friendly_id, который, вероятно, наиболее часто используется для управления дружественными идентификаторами для Rails.

Кроме того, хотя мне нравятся красивые URL, я думаю, что важно помнить, что это, скорее всего, функция, используемая более опытными технически подкованными пользователями. Некоторые браузеры даже начинают скрывать URL-адреса (или их часть).

— mbillard
источник

2

Эта история слизняков - то, что я рассматривал. С момента публикации вопроса я заметил много крупных сайтов с именами, которые не проверены, вы можете изменить его, чтобы сказать что угодно. amazon.co.uk/Blah-Blah-Blah/dp/B004R276L8 работает. StackExchange умен, так как он «исправляет» и перенаправляет браузер, чтобы обеспечить отображение и распространение нужной ссылки.

— Люк Пуплетт

«Слаг» менее полезен для людей и более полезен для поисковой оптимизации, поскольку «слаг» или «дружественный URL» должны содержать ключевые слова, относящиеся к содержанию страницы. Опытные пользователи не являются причиной для включения дружественных URL на ваш сайт. Ранжирование в поисковых системах, как правило, является основной причиной.

— Грег Бергхардт

Я не согласен. Трудно работать с URL-адресами только с идентификаторами; из списка трудно вспомнить, к какому из них можно вернуться. Или будет ли что-то неуместное на другом конце ссылки. Адресная строка Chrome также указывает на любую часть URL, что полезно.

— Люк Пуплетт

1

@ LukePuplett да, я считаю, что SE справляется с URL-адресами проще всего, когда речь идет о слизняках.

— Мбиллард

@GregBurghardt единственная разница в рейтинг кликов, пользователи склонны нажимать немного больше на дружественных URL: stackoverflow.com/questions/505793/…

— mbillard

3

Я использовал два разных сценария в прошлом.

/id/some-slugгде используется для поиска , слизняка нет. Таким образом, слизняк может быть чем угодно . Но когда слаг не совпадает с реальным слагом, пользователь перенаправляется на текущую версию.id
/permalinkдля случаев, когда мы не хотим, чтобы идентификатор в URL или URL никогда не должен меняться, даже если есть доступный идентификатор (см. [1] и [2] ). Конечно, в этом случае используется для поиска . И текущий слаг, и постоянная ссылка (первый слаг) сохраняются в базе данных.permalink

Ни одним из этих способов вам не нужно хранить историю слагов в вашей базе данных, что очень скоро станет проблематичным.

PS: Во втором случае вам понадобится очень специфическая маршрутизация для хранения социальных кредитов:

если хотите, перенаправьте пользователей на текущий (не постоянный) URL
использовать постоянную ссылку в качестве URL в социальных кнопках
всегда перенаправлять сканер facebook на постоянную ссылку

Смотрите [1] и [2] снова.

— залежь
источник

Почему это будет проблематично? Если я сохраню и ID и слаг будет чем-то, посетитель перейдет на реальную страницу. Будет ли это вредно для SEO?

— Джнанаранджан

Вы имеете в виду вести историю слизней? Что вы делаете, когда кто-то хочет повторно использовать такой слизень? Для того же или другого идентификатора? Как вы проектируете базу данных и / или код для предотвращения множественных перенаправлений? Вы хотите скрыть существование после удаления и перенаправления выставляют предыдущее существование? Все это не невозможно, но это поднимает всевозможные вопросы, которые я предпочитаю просто замышлять.

— Лоде

Я хотел сказать, что если идентификатор присутствует в URL-адресе, то независимо от того, что это за фрагмент, он будет перенаправлен на запрашиваемую страницу. Тогда история слизней не имеет значения. Я согласен, что это проблематично для Android, хотя.

— Джнанаранджан

1

Ах хорошо. Это то, что я добавил сценарий 1 правильно? Или ты имеешь в виду что-то еще?

— Лоде

Да. Это правильно.

— Джнанаранджан

2

Что происходит, когда документ или продукт переименовывается?

HTTP-ответ 301 (перемещен) был разработан для этой цели. Если какой-либо клиент переходит на старый URI, вы просто отправляете ему новый URI, и они могут перенаправить на него.

Бит раздвижных дверей не является уникальным и только генерируется из заголовка видео, его можно проверить по GET, поэтому, если скользящие двери были введены и не соответствуют тому, что на самом деле в документе 287171, они отвечают 404.

Если я правильно понимаю, это дублирующая работа, у вас есть и идентификатор имени ресурса, и идентификатор в одном и том же URI. Это не служит никакой цели.

Если вас беспокоит несколько фильмов с одинаковым названием, вы можете добавить дополнительную информацию о фильме в URL

http://vidsyeah.com/video/2000/sliding_doors
http://vidsyeah.com/video/1932/sliding_doors

или

http://vidsyeah.com/video/studios/paramount/sliding_doors
http://vidsyeah.com/video/studios/warnerbros/sliding_doors

Сказав, что нет ничего плохого в использовании идентификаторов, если это имеет смысл для вашей модели данных, особенно если вы группируете только то, что это видео.

http://vidsyeah.com/video/210232
http://vidsyeah.com/video/2342

Клиент, компьютер или пользователь, не должен в первую очередь полагаться на структуру URI, он должен смотреть на содержимое, которое вы вернули, чтобы выяснить, какой ресурс найти.

Нет ничего плохого в том, чтобы иметь разумную систему URI, которая позволяет кому-то легко угадать местоположение ресурса или перемещаться вверх и вниз по структуре на основе общих свойств (то есть всех фильмов в 2004 году), но ваша система не должна полагаться на этом, и ни один клиент не должен сломаться, если вы измените свои URI

Или, другими словами, вы сможете измениться за ночь с

http://vidsyeah.com/video/studios/paramount/sliding_doors

в

http://vidsyeah.com/video/12323

и ни один клиент не должен сломаться, потому что клиенты должны смотреть на контент, а не на URL.

— Кормак Мулхолл
источник

Как и ответ Джона, я думаю, что вы не носите свою шляпу UX, когда думаете об этом. Я хочу повысить удобство использования адреса. См. Мой комментарий в вопросе: «Мне нравятся дружественные URL-адреса, поскольку у вас есть представление о том, что находится в конце URL-адреса, когда вы наводите указатель мыши или видите его в электронном письме или документе. Это лучше для SEO, или раньше».

— Люк Пуплетт

2

Чтобы бросить 301, мне нужно было бы найти правильный ресурс, поэтому мне нужна история.

— Люк Пуплетт

1

Вам нужна история, но если у вас есть сайт с ресурсами, которые меняются, это хорошая идея в любом случае.

— Кормак Мулхолл,

Нет проблем с дружественными URI. Я бы не стал делать схему, что URI может быть чем угодно, но все равно работать, если в конце у него есть идентификатор. Это на самом деле не решает никаких проблем (пользователь все еще должен помнить идентификатор) и вводит в заблуждение схему URI (пользователь может законно спросить, почему два разных URI, один с орфографической ошибкой, переходят на один и тот же ресурс)

— Кормак Малхолл

1

Если вас беспокоят орфографические ошибки в URI, то для решения этой проблемы рекомендуется использовать URI на странице ошибок 404 для неправильно записанного URL. Вы можете выполнить поиск по шаблону и вернуть то, что, по вашему мнению, может искать пользователь.

— Кормак Малхолл,

1

BBC используют слизней, которые:

буквенно-цифровой (для компактности)
уникальный (для поисков)
непоследовательный (так что порядок добавления вещей в БД не выставляется)

например, http://www.bbc.co.uk/programmes/b006mk7h

У каждой общедоступной программы есть и идентификатор, и слаг. Идентификаторы могут, как обычно, автоматически увеличивать целые числа, и пропуски не отображаются.

— Николас Шэнкс
источник

0

С точки зрения RESTful, URI должны следовать предсказуемой и допускающей иерархической структуре для повышения удобства использования.

Это облегчит их использование потребителями. Если ваши данные имеют отношения, то потребуется какая-то иерархия.

Похоже схема такая: \video\[name]\[id]

Если имя не используется для какой-либо дальнейшей классификации, оно может быть отклонено в пользу \video\[id].

Однако, если вы хотите классифицировать видео, тогда, возможно, название будет полезным.

Примеры:

\ видео \ SwingingDoors \ 123
\ видео \ SwingingDoors \ 124
\ видео \ SlidingDoors \ 125
\ видео \ SlidingDoors \ 126

Это действительно дизайнерское решение о том, как моделируется доступ.

— Джон Рейнор
источник

Я думаю, что вы думаете об этом из информационной архитектуры API / сайта PoV. Я хотел представить сгенерированную дружественную часть URL, чтобы помочь людям и SEO. По-видимому, это обычное дело и называется «слизняк». Имя не используется для классификации и добавляется (не удаляется) для улучшения UX с URL и нашим сайтом / брендом.

— Люк Пуплетт