Comments 23
Я думаю в идеале лучше делать без s, но со страницы /article/ перенаправлять на /articles/, где находится индекс.
Если честно в одном из проектов задумался над этим же и сделал вот так:
Если списки, то domain.com/users/, а если конкретный юзер, то darwin.domain.com ну и там пошло — darwin.domain.com/photo/, darwin.domain.com/settings/ и т.д. =)
Если списки, то domain.com/users/, а если конкретный юзер, то darwin.domain.com ну и там пошло — darwin.domain.com/photo/, darwin.domain.com/settings/ и т.д. =)
чем "/users/vasya" плохо звучит?
Нормально делается так:
/user/ — это твоя собственная страница, т.е. твой собственный профайл с возможностью изменения (или редирект на него). /user/{username} — профайл пользователя, в том числе и твой если логин соответствующий. Или же, /user/ — 404 страница, что очень даже логично.
/users/ — это именно список, причем тут есть творчество для фильтров: /users/all/, /users/friends/, /users/active/ и др.
Это я все к тому, что индекс и просмотр — это разные сущности, и мешать их нельзя (если не REST конечно). Вот почему: если у вас url /user/, то делее может быть только логин, и следовательно пространоство для фильтров с случае списка идет через гет-параметры, что не всегда хорошо.
Тоже касается остальных.
Да, если речь идет о REST — Там жестко — /user/ — индекс, /user/{login} — ресурс.
/user/ — это твоя собственная страница, т.е. твой собственный профайл с возможностью изменения (или редирект на него). /user/{username} — профайл пользователя, в том числе и твой если логин соответствующий. Или же, /user/ — 404 страница, что очень даже логично.
/users/ — это именно список, причем тут есть творчество для фильтров: /users/all/, /users/friends/, /users/active/ и др.
Это я все к тому, что индекс и просмотр — это разные сущности, и мешать их нельзя (если не REST конечно). Вот почему: если у вас url /user/, то делее может быть только логин, и следовательно пространоство для фильтров с случае списка идет через гет-параметры, что не всегда хорошо.
Тоже касается остальных.
Да, если речь идет о REST — Там жестко — /user/ — индекс, /user/{login} — ресурс.
Кину в карму +. Мне понравилась идея
> Да, если речь идет о REST — Там жестко — /user/ — индекс, /user/{login} — ресурс.
Как раз /user/ и будет ресурсом. И вообще, в REST не задано жестко, что нельзя использовать множественное число.
Я придерживаюсь мнения, что лучше использовать множественную форму.
И сделал бы так:
/users/ — список пользователей
/users/new — страница создания нового пользователя
/users/vasya — конкретный пользователь (профиль)
/users/vasya/settings — настройки пользователя
/users/vasya/edit — страница редактирования пользовательских данных
Как раз /user/ и будет ресурсом. И вообще, в REST не задано жестко, что нельзя использовать множественное число.
Я придерживаюсь мнения, что лучше использовать множественную форму.
И сделал бы так:
/users/ — список пользователей
/users/new — страница создания нового пользователя
/users/vasya — конкретный пользователь (профиль)
/users/vasya/settings — настройки пользователя
/users/vasya/edit — страница редактирования пользовательских данных
Ага. А вот теперь что будет, если пользователь захочет себе логин «new»? Будете на уровне скриптов ставить проверки логинов, которые нельзя создавать?
> Как раз /user/ и будет ресурсом. И вообще, в REST не задано жестко, что нельзя использовать множественное число.
Да, ресурсом типа индекс. Т.е. списоком.
Я говорил не про множественное число, а про сам порядок. Т.е. индекс не разделен от ресурса в плане структуры URL.
> Как раз /user/ и будет ресурсом. И вообще, в REST не задано жестко, что нельзя использовать множественное число.
Да, ресурсом типа индекс. Т.е. списоком.
Я говорил не про множественное число, а про сам порядок. Т.е. индекс не разделен от ресурса в плане структуры URL.
У меня на одном из проектов:
/[category]s — список элементов (с постраничной разбивкой: /[category]s/2, /[category]s/3 и т.п.)
/[category]/[id] — отдельный элемент
/[category] -> /[category]s (если кто случайно зайдет).
Например:
/users
/user/1
/user/s
/quotes
/quote/1
/quote/2
/[category]s — список элементов (с постраничной разбивкой: /[category]s/2, /[category]s/3 и т.п.)
/[category]/[id] — отдельный элемент
/[category] -> /[category]s (если кто случайно зайдет).
Например:
/users
/user/1
/user/s
/quotes
/quote/1
/quote/2
Ошибся:
/users
/user/1
/user/2
…
/users
/user/1
/user/2
…
Да и не categorys, наверное, а categories. :)
Конечно, спасибо.
3й выходной плохо влияет на мою внимательность :)
3й выходной плохо влияет на мою внимательность :)
Верно подмечено. И схема URI идиотская. Глупо делать 2 разных URI, которые ведут на одну и ту же страницу.
Эту же схему я упомянул в первом комментарии. Но это не совсем два URI, это вполне осмысленное перманентное перенаправление. Почему-то сейчас вспомнился сайт Лебедева: если попробовать зайти на tema.ru/trave, то вас автоматически перенаправит на travel.
На сайте Лебедева скорее всего стоит mod_negotiation httpd.apache.org/docs/2.0/mod/mod_negotiation.html или что-то подобное.
Минусы такой схемы — /users это файл, а не директория, неоднозначто что там должен быть список.
Что будет на страницах /user/ и /quote/?
Как вариант при такой схеме:
/users
/user-1
/user-2
Хотя мне больше нравится классический вариант:
/users/
/users/1
/users/2
и при этом /users будет перенаправляться на /users/, собственно так и работает, если всё правильно настроено.
Что будет на страницах /user/ и /quote/?
Как вариант при такой схеме:
/users
/user-1
/user-2
Хотя мне больше нравится классический вариант:
/users/
/users/1
/users/2
и при этом /users будет перенаправляться на /users/, собственно так и работает, если всё правильно настроено.
в рельсах качественно организовано ЧПУ:
guides.rubyonrails.org/routing.html#crud-verbs-and-actions
guides.rubyonrails.org/routing.html#crud-verbs-and-actions
URL не должен читаться как текст. Это обозначения разделов. Есть раздел «пользователи», но нет раздела «пользователь».
кстати, та же фигня с именами массивов, списков и коллекций
users, userList, userIds
особенно в составных именах: userPhotos — список фоток юзера, тут, вроде, понятно
а если список списков? ну, массив массивов — usersPhotos?
кто как именует переменные?
users, userList, userIds
особенно в составных именах: userPhotos — список фоток юзера, тут, вроде, понятно
а если список списков? ну, массив массивов — usersPhotos?
кто как именует переменные?
Это отдельная тема для разговора. Можно еще затронуть схему БД. Я считаю, что коллекции, содержащие множество сущностей, должны называться во множественном числе. Не важно, массив ли это, таблица БД, или часть URI.
Поддерживаю Вас, действительно название таблиц в БД следует именовать во множественном числе. Современные инструменты ORM умеют преобразовывать Plural в Singular такие как Linq to Sql. Стоит писать Users и UserAddresses (НЕ! UsersAddresses) есть еще UserAddressesVerification (HE! Verifications) в БД. То же на мой взгляд и с урлами, на мой взгляд лучше поддерживать /Users/All для списков (параллель таблицы) НО! /User/Vasya (экземпляр объекта) для примера возьмите сайт apple.com и их ЧПУ.
Sign up to leave a comment.
Красивый URL, как лучше?