Соглашение REST для ресурсов с косой чертой

Существует ли какое-либо соглашение REST для обработки ресурсов с косой чертой?

Например, предположим, что обычный ресурс REST работает так:

  • /ice cream/chocolate - возвращает ингредиенты шоколадного мороженого
  • /ice cream/rocky road - возвращает ингредиенты мороженого "Каменная дорога"
  • /ice cream/strawberry/banana - возвращает ингредиенты клубничного банана

Только /ice cream/strawbery/banana не совсем работает, потому что это похоже на ресурс для клубники с подкомпонентом банана.... не совсем то, что нам нужно.

Когда вы пытаетесь избежать '/' с помощью '%2F', многие веб-серверы (включая Glassfish и Apache) блокируют это по умолчанию как возможное нарушение безопасности. Есть переопределение сервера, но тогда мне нужно будет привлечь другую команду... Я бы предпочел сам справиться с этим.

Так что же делать человеку с RESTful разумом? Я не могу помешать кому-то назвать свое мороженое «клубничным/банановым».

Я думал об использовании какой-нибудь пользовательской escape-последовательности, такой как stawberry*slash*banana, а затем заставить любой компонент дисплея выполнить преобразование на своей стороне, но я подумал, что другие, должно быть, сталкивались с подобными проблемами, так почему бы не спросить о наилучшей практике (или, по крайней мере, о некоторых идеях). Это имеет смысл)?


rest conventions
person Vinnie    schedule 27.10.2010    source источник
comment
Что делать, если у вас есть ресурс PATHS, который содержит метаданные о пути. мне кажется, что это должно поддерживаться RESTful API, иначе это ненужное ограничение парадигмы. С какой проблемой вы сталкиваетесь при кодировании?   -  person magritte    schedule 30.01.2017

Ответы (2)


arrow_upward
2
arrow_downward

Посмотрите, что переполнение стека делает с их вопросами. Они добавляют дефис вместо пробела. Вы можете сделать то же самое, заменив косую черту дефисом. Таким образом, вы сохраняете удобочитаемость вашего URI, но избегаете зарезервированных символов.

Вам не нужно, чтобы имя ресурса точно сопоставлялось с названием мороженого, потому что вы никогда не должны создавать URI, используя имя. Если кто-то хочет найти клубнично-банановое мороженое, он должен искать по некоторым критериям, вы показываете список совпадений со ссылками, и они выбирают клубнично-банановый. Пользователю все равно, что вы заменили косую черту на дефис, потому что название мороженого все еще содержит косую черту.

person Darrel Miller    schedule 28.10.2010

arrow_upward
0
arrow_downward

если вы настраиваете URI, вы можете решить, как кодировать URI. Чтобы быть действительно RESTful, URI на самом деле не должен иметь смысла. /XYZ/12345 может быть шоколадным, а /ABC/zzzzz - каменистой дорогой. Все зависит от тебя. Вы решили придать своему URI какой-то смысл и теперь столкнулись с этой проблемой с косой чертой в URI, но это не имеет ничего общего с REST, а с вашим собственным соглашением о кодировании URI. На самом деле REST предпочел бы, чтобы вы перечисляли свои ресурсы из некоторой базовой отправной точки, а затем пользователи перемещались, используя предоставленные вами URI. Вы можете предоставить список (в другом формате) как:

Chocolate Ice Cream http://base.com/XYZ/12345
Rocky Road Ice Cream http://base.com/ABC/zzzzz
Strawberry/Banana Ice Cream http://base2.com/G789

и пользователи перемещаются оттуда.

person Paul Morgan    schedule 27.10.2010
comment
+1 для URI на самом деле не обязательно иметь значение. Это теряется в крике о чистых URL-адресах. - person rojoca; 01.11.2010