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

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

3 голосов
/ 22 сентября 2008

Одна из многих вещей, которых мне не хватало в моей службе скребков , которую я настроил на прошлой неделе, - это красивые URL-адреса. Прямо сейчас пользовательский параметр передается в сценарий с ? U = , что является признаком ленивого взлома (который, по общему признанию, является сценарием). Тем не менее, я думал о том, чтобы переделать его, и я хотел бы получить некоторые отзывы о доступных опциях. Прямо сейчас есть две страницы, обновление и диаграмма, которые предоставляют информацию пользователю. Вот две возможности, которые я придумала. «1234» - это идентификационный номер пользователя. По техническим причинам имя пользователя, к сожалению, не может быть использовано:

  • http://< tld> / update / 1234
  • http://< tld> / график / 1234

или

  • http://< tld> / 1234 / update
  • http://< tld> / 1234 / график

Параметр # 1 концептуально вызывает обновление с идентификатором пользователя. Вариант № 2 предоставляет глагол для работы с идентификатором пользователя.

С точки зрения согласованности, что имеет больше смысла?

Другая упомянутая опция -

  • http://< tld> / user / 1234 / update
  • http://< tld> / user / 1234 / chart

Это обеспечивает место для страниц, не относящихся к конкретному пользователю. т.е.

  • http://< tld> / stats

Ответы [ 9 ]

6 голосов
/ 24 сентября 2008

Если вы воспользуетесь этой схемой, станет проще остановить роботов-роботов от вашего сайта: 

 http://< tld >/update/1234
 http://< tld >/chart/1234

Это потому, что вы можете настроить файл /robots.txt, содержащий: 

 Disallow /update/
 Disallow /chart/

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

5 голосов
/ 22 сентября 2008

Я бы мягко склонялся к ведению с помощью идентификатора пользователя - опция # 2 - поскольку (то, что существует) структура каталогов - это две разные функции над данными пользователя. Это диаграмма пользователя и обновление пользователя.

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

  • Все ли впереди будет дополнительными функциями foo, bar и baz для отдельных пользователей? Если это так, вариант № 2 становится более привлекательным по вышеуказанной причине - идентификатор пользователя является базовыми данными, поэтому имеет смысл начать с него семантически.
  • Собираетесь ли вы добавить неуправляемую функциональность? В этом случае может иметь смысл указывать заголовок каталога: / user / 1234 / update, / user / 1234 / chart, / question / 45678 / activity, / question / 45678 / stats и т. Д.
5 голосов
/ 22 сентября 2008

Опция # 1 соответствует распространенным примерам ASP.NET MVC. Некоторые из примеров в Model View Controller модель имеют форму {controller} / {action} / {id}. В быстром запуске .NET 3.5 по маршрутизации есть таблица, показывающая некоторые допустимые шаблоны маршрутов:

Определение маршрута - Пример соответствия URL

{контроллер} / {действие} / {ID} - / Продукция / шоу / напитки

{таблица} /Details.aspx - /Products/Details.aspx

блог / {действие} / {запись} - / блог / шоу / 123

{ReportType} / {год} / {месяц} / {день} - / sales / 2008/1/5

{локали} / {действие}
- / en-US / шоу

{язык} - {страна} / {действие}
- / en-US / шоу

4 голосов
/ 22 сентября 2008

Мне лично нравится этот стиль, потому что он сохраняет пользователя таким же, но дает вам конкретное представление о них.

  • http://< tld> / 1234 / update
  • http://< tld> / 1234 / график

Если бы вы пошли другим путем, я ожидал, что смогу увидеть все в / update или / chart, а затем сузить его по пользователю.

1 голос
/ 24 сентября 2008
1 голос
/ 22 сентября 2008

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

0 голосов
/ 26 сентября 2008

Если есть способ перечисления пользователей, я бы представил сегмент пользователей: 

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
0 голосов
/ 22 сентября 2008

Конвенция гласит объект / глагол / ID, поэтому должно быть:

http://< tld> / user / update / 1234

(Я только что заметил, что соответствует вашему обновленному вопросу:)

Так что да, # 3 - лучший выбор.

Это поддерживает не пользовательские операции, как вы упомянули (stats /), а также многопользовательские операции:

http://< tld> / user / list /

0 голосов
/ 22 сентября 2008

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

...