Дружественная схема URL-адресов?

StackOverflow https://stackoverflow.com/questions/112695

  •  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
Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top