Дружественная схема URL-адресов?
-
02-07-2019 - |
Вопрос
Одна из многих вещей, которых мне не хватало скребковый сервис которые я установил на прошлой неделе, — это красивые URL-адреса.Прямо сейчас пользовательский параметр передается в скрипт с помощью ?u=, что является признаком ленивого взлома (которым, по общему признанию, и является сценарий).Однако я подумывал о его переделке и хотел бы получить отзывы о доступных вариантах.На данный момент есть две страницы: обновление и диаграмма, которые предоставляют информацию пользователю.Вот две возможности, которые я придумал.«1234» — это идентификационный номер пользователя.К сожалению, по техническим причинам имя пользователя не может быть использовано:
- http://< домен >/update/1234
- http://< домен >/chart/1234
или
- http://< домен >/1234/update
- http://< домен >/1234/chart
Концептуально вариант №1 вызывает обновление с идентификатором пользователя.Вариант №2 предоставляет команду для работы с идентификатором пользователя.
С точки зрения последовательности, что имеет больше смысла?
Еще один упомянутый вариант
- http://< домен >/user/1234/update
- http://< домен >/user/1234/chart
Это обеспечивает место для страниц, не относящихся к конкретному пользователю.то есть
- http://< домен >/stats
Решение
Я был бы склонен начать с идентификатора пользователя - вариант № 2 - поскольку (то, что существует) структура каталогов - это две разные функции над данными пользователя.Это диаграмма пользователя и обновление пользователя.
Однако это довольно незначительный момент, если не знать, есть ли планы по значительному расширению функциональности этой штуки.
- Будут ли в будущем добавлены дополнительные функции foo, bar и baz для отдельных пользователей?Если да, то вариант №2 становится более привлекательным по вышеуказанной причине: идентификатор пользователя является основными данными, поэтому имеет смысл начать с него семантически.
- Собираетесь ли вы добавить функциональность, не управляемую пользователем?Тогда может иметь смысл использовать каталог заголовка — /user/1234/update, /user/1234/chart, /question/45678/activity, /question/45678/stats и т. д.
Другие советы
Если вы воспользуетесь этой схемой, вам будет легко запретить (хорошим поведением) роботам просматривать ваш сайт:
http://< tld >/update/1234
http://< tld >/chart/1234
Это связано с тем, что вы можете настроить файл /robots.txt, содержащий:
Disallow /update/
Disallow /chart/
Для меня это приятный бонус, который часто упускают из виду.
Вариант №1 соответствует обычным примерам ASP.NET MVC.Некоторые примеры на Контроллер представления модели модель имеет вид {controller}/{action}/{id}.А Краткое руководство по маршрутизации в .NET 3.5 имеет таблицу, показывающую некоторые допустимые шаблоны маршрутов:
Определение маршрута - пример соответствующего URL
{Controller}/{action}/{id} -/products/show/beverages
{table} /details.aspx - /products/details.aspx
blog/{action}/{inpit} -/blog/show/123
{reportType}/{Год}/{месяц}/{день} -/sales/2008/1/5
{локаль}/{действие}
-- /en-US/показать
{язык}-{страна}/{действие}
-- /en-US/показать
Лично мне нравится этот стиль, потому что он сохраняет пользователя неизменным, но дает вам конкретное представление о нем.
- http://< домен >/1234/update
- http://< домен >/1234/chart
Если бы вы пошли другим путем, я бы ожидал, что смогу увидеть все в /update или /chart, а затем сузить список по пользователю.
Выбирайте последнее;URL-адреса должны быть иерархическими (или, по крайней мере, пользователи читают их таким образом по аналогии с путями к локальным каталогам).Здесь основное внимание уделяется различным представлениям конкретного пользователя, поэтому понятие «пользователь» является более общим и должно стоять первым.
Я просто ответил на вопрос «Как вы структурируете свои URL-маршруты?» с моим мнением о том, как сделать URL-адреса RESTful, взломанными и удобными для пользователя.Я думаю, что лучше было бы дать ссылку, чем писать что-то подобное в этом вопросе, отсюда и ссылка.
Я согласен, что с точки зрения контекста приложение, за которым следуют параметры, имеет для меня гораздо больше смысла, чем суррогатный ключ для элемента, за которым следует контекст того, что это за элемент.В конечном счете, я бы посоветовал вам программировать то, что для вас более естественно.
В соглашении говорится об объекте/глаголе/идентификаторе, поэтому должно быть так:
http://< домен >/user/update/1234
(Я только что заметил, что это соответствует вашему обновленному вопросу :)
Так что да, №3 — лучший выбор.
Как вы упомянули, это поддерживает непользовательские операции (stats/), а также многопользовательские операции:
http://< домен >/user/list/
Если есть способ составить список пользователей, я бы представил сегмент пользователей:
http://< tld >/users/ <--- user list
http://< tld >/users/1234/ <--- user profile, use overloaded POST on this to update.
http://< tld >/users/1234/chart/ <--- user chart
Если вы можете видеть только свои собственные данные, т. е. пользователи невидимы друг для друга, вам не нужен идентификатор пользователя, поскольку вы можете получить его из сеанса, и в этом случае:
http://< tld >/user/ <--- user profile, use overloaded POST on this to update.
http://< tld >/user/chart/ <--- user chart