Структура URL, лучшие практики / стандарты - PullRequest
Новая
       14

Структура URL, лучшие практики / стандарты

3 голосов
/ 15 октября 2011

Я создаю сайт, на котором есть элементы, причем каждый элемент имеет страницу, например: 

website.com/book/123
website.com/film/456
website.com/game/789

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

Мой вопрос: существуют ли какие-либо стандарты или лучшие практики для структурирования URL-адресов длястраницы, связанные с элементом?Например: 

website.com/film/456/gallery

Где подстраница идет после элемента или: 

website.com/film/gallery/456/

, где элемент является самой последней частью URL.

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

загрузка веб-сайта.com -> нажмите «фильмы» (website.com/films) -> нажмите «фильм» (website.com/film/123) -> щелкните галерею (website.com/)фильм / 123 / галерея)

но что-то в этом кажется ... выкл, непоследовательно.

1 Ответ

4 голосов
/ 15 октября 2011

Вы правы в том, что предыдущий URL «лучше» и используется более широко.Я не думаю, что вы найдете это документированным в каком-либо стандарте ;это скорее конвенция.Большинство статей и книг, посвященных REST, делают это таким образом.

Причина этого, как вы говорите, в том, что компоненты пути в URL соответствуют структуре ресурсов и подресурсов.В частности, все следующие адреса должны быть действительными:

  • website.com /
  • website.com / books
  • website.com / books / 123

В частности, обратите внимание, что books/123, не book/123, как у вас.Я видел единственное число, но имхо множественное число лучше.

Для URL /books

  • GET получает все книги, но вы можете ограничить книги параметрами запроса, например/books?author=alice
  • a POST добавляет новую книгу (с идентификатором, сгенерированным сервером).

Для URL /books/123

  • a GETполучает эту конкретную книгу
  • , PUT заменяет книгу с этим идентификатором (или добавляет книгу с этим сгенерированным клиентом идентификатором)

Теперь, если в книге есть пятна, а пятна уникальны только для определенной книги , тогда вы добавите следующие URL:

  • website.com / books / 123 / blurbs
  • website.com / books / 123/ blurbs / 72

Вы можете сделать то же самое для фильмов и галерей, при условии, что каждая галерея принадлежит одному фильму.Но если бы галереи существовали для нескольких фильмов, вы бы сделали /galleries URL верхнего уровня.Переход от фильма к галерее все равно будет в порядке.У вас не будет структурированного URL.Вместо этого вы получите все галереи, содержащие изображения из фильма 456, через GET на

  • website.com / galleries? Film = 456

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

Теперь, наконец, прямо отвечу на ваш вопрос: website.com/films/galleries/456 не очень хороший URL, ИМХО, потому что `website.com/films/galleries/ не очень полезен.На самом деле я думаю, что это довольно некрасиво.Что бы это значило?Все галереи?Если это так, это должно быть website.com/galleries.

Опять же, я не думаю, что это где-то стандартизировано, но это кажется очень распространенным и традиционным.

...