RESTful красивый дизайн URL предназначен для отображения ресурса на основе структуры (структура, похожая на каталог, дата: article / 2005/5/13, объект и его атрибуты, ..), косая черта /
указывает на иерархическую структуру, вместо нее используйте -id
.
Иерархическая структура
Я бы лично предпочел:
/garage-id/cars/car-id
/cars/car-id #for cars not in garages
Если пользователь удаляет часть /car-id
, он обеспечивает предварительный просмотр cars
- интуитивно понятный. Пользователь точно знает, где в дереве он находится, на что он смотрит. С первого взгляда он знает, что гаражи и машины связаны между собой. /car-id
также означает, что он принадлежит друг другу в отличие от /car/id
.
Поиск
Поисковый запрос в порядке, так как он , есть только ваши предпочтения, что следует учитывать. Самое смешное происходит при объединении поисков (см. Ниже).
/cars?color=blue;type=sedan #most prefered by me
/cars;color-blue+doors-4+type-sedan #looks good when using car-id
/cars?color=blue&doors=4&type=sedan #I don't recommend using &*
Или, по сути, все, что не является косой чертой, как описано выше.
Формула: /cars[?;]color[=-:]blue[,;+&]
, * хотя я бы не использовал знак &
, так как он неузнаваем по тексту на первый взгляд.
** Знаете ли вы, что передача объекта JSON в URI является RESTful? **
Списки опций
/cars?color=black,blue,red;doors=3,5;type=sedan #most prefered by me
/cars?color:black:blue:red;doors:3:5;type:sedan
/cars?color(black,blue,red);doors(3,5);type(sedan) #does not look bad at all
/cars?color:(black,blue,red);doors:(3,5);type:sedan #little difference
возможных функций?
Строки поиска с отрицанием (!)
Для поиска любых автомобилей, кроме не черного и красного :
?color=!black,!red
color:(!black,!red)
Поисковые запросы
Поиск красный или синий или черный автомобили с 3 дверьми в гаражах id 1..20 или 101..103 или 999 , но не 5
/garage[id=1-20,101-103,999,!5]/cars[color=red,blue,black;doors=3]
Затем вы можете построить более сложные поисковые запросы. (Посмотрите на соответствие атрибута CSS3 для идеи соответствия подстрок. Например, поиск пользователей, содержащих "bar" user*=bar
.)
Заключение
В любом случае, это может быть самой важной частью для вас, потому что вы можете делать это как угодно, просто имейте в виду, что RESTful URI представляет собой структуру, которая легко понимается, например, каталогоподобные /directory/file
, /collection/node/item
, даты /articles/{year}/{month}/{day}
.. И когда вы пропускаете какой-либо из последних сегментов, вы сразу же знаете, что получаете.
Итак, все эти символы разрешены в незашифрованном виде :
- незарезервировано:
a-zA-Z0-9_.-~
- зарезервировано:
;/?:@=&$-_.+!*'(),
- небезопасно *:
<>"#%{}|\^~[]`
* Почему небезопасно и почему лучше кодировать: RFC 1738 см. 2.2
RFC 3986 см. 2.2
Несмотря на то, что я ранее сказал, здесь есть общее различие делимеров, означающее, что некоторые являются ' более важными, чем другие.
- общие разделители:
:/?#[]@
- Субделиметры:
!$&'()*+,;=
Подробнее:
Иерархия: см. 2.3 , см. 1.2.3
Синтаксис параметра пути URL
Соответствие атрибута CSS3
IBM: RESTful Web-сервисы - основы
Примечание: RFC 1738 был обновлен RFC 3986