REST - несколько URI для того же ресурса (???)
Я пишу работу о реализации сервиса REST для научно-исследовательских работ университета, и у меня есть небольшая проблема при понимании отношений между URIs и Ресурсами.
Это говорит, что ресурс может иметь один URI или многих. Таким образом, вот моя проблема. Я хочу сделать этот сервис очень простым в использовании и обойти информацию: к ресурсу нужно получить доступ от другого entrypoints, но это будет идти вразрез с понятием, что каждый "URI определяет точно один ресурс".
Таким образом, мой вопрос состоит в том, если следующее - он или является им не в соответствии с REST следующее:
Я хочу представить информацию о публикации исследования (скажем, рассмотренный одноранговый узел).
К этому может получить доступ этот URI: UNIVERSITY/publications/{my_publication}.
Но так как данная статья записана исследователем, который работает в скажем, Факультете Социологии, она будет также иметь смысл, что публикация имеет этот URI: UNIVERSITY/faculties/social_science/publications/{my_publication}.
Далее больше, как сервис также представляют всех исследователей, работающих в университете (например, UNIVERSITY/researchers/{my_researcher}) он будет также иметь смысл, которым публикацию можно назвать как UNIVERSITY/researchers/{my_researcher}/publications/{my_publication}.
Это могло продолжать несколько вариантов использования, но Вы получаете идею.
Соответствует этому REST или нет?
Я могу сохранить это и решить дилемму путем отправки кода ответа 303 ("Видят также") наряду с каноническим URI (который, будет UNIVERSITY/publications/{my_publication}).
Заранее спасибо!
5 ответов
Хотя каждый ресурс публикации должен иметь один и только одно имя ресурса (URI), вы можете создавать ресурсы, которые являются запросами и возвращают списки других имен ресурсов.
Вы можете использовать UNIVERSITY / publishing / {publishing} в качестве шаблона имени ресурса для ресурсов публикации, и УНИВЕРСИТЕТ / факультеты / {факультеты} / публикации как образец для наименования ресурсов, которые представляют собой списки публикаций для определенных факультетов. Аналогичным образом UNIVERSITY / research / {исследователь} / публикации может быть шаблоном названия ресурса для списков публикаций, созданных конкретным человеком.
В нем говорится, что у ресурса может быть один или несколько URI. Итак, вот моя проблема. Я хочу сделать эту службу очень простой в использовании и обойти информацию: доступ к ресурсу должен осуществляться из разных точек входа, но это будет противоречить концепции, согласно которой каждый «URI обозначает ровно один ресурс».
Я не знаю ' Не думаю, что здесь есть противоречие. URI может указывать максимум на один ресурс, но многие URI могут указывать на один и тот же ресурс. Отношения «многие к одному» между URI и ресурсами, если хотите.
Тем не менее, я бы не сильно волновался, является ли ваше приложение RESTful или нет. Это просто принцип дизайна. Вот хорошая статья парня, который утверждает, что REST на самом деле не предназначен для людей с веб-браузерами: http: //starkravingcoder.blogspot. com / 2009/01 / where-are-rest-frameworks.html
Это часто обсуждаемая тема, и я считаю, что путаница основана на попытке понять, на что на самом деле указывает HTTP URI. Судя по моим прочтениям, это становится действительно непростой темой, и люди умнее меня много лет спорили на эту тему.
Здесь - это сводная страница всего обсуждения проблемы http-range-14.
Моя наивная интерпретация окончательного вывода по этой проблеме состоит в том, что должен быть только один URI, который возвращает физический «информационный ресурс» с 200. Однако может быть много URI, которые относятся к ресурсу как к чистой концепции. Возвращение 303 позволяет связать концепцию с «информационным ресурсом».
Итак, ответ - да и нет, может быть несколько URI для одного и того же ресурса, и все они действительны для представления концепции, но только один должен фактически возвращать физическое представление.
Это согласуется с недавним комментарием Роя Филдинга, когда он говорил об использовании «.xml» и «.json» в URI. Он довольно четко заявил, что http://www.example.org/myresource.xml и http://www.example.org/myresource.json относятся к двум различным РЕСУРСАМ. потому что они оба возвращают 200. Однако, когда вы используете согласование контента на http://www.example.org/myresource , вы можете получить два разных представления одного и того же ресурса.
+1 Джиму Феррансу.
Кроме того, наличие ровно одного URI для каждого ресурса упростит создание ссылок на вашем сайте. Я читал, что поисковые системы также предпочитают, чтобы контент не повторялся с разными URI.
Он говорит, что у ресурса может быть один или несколько URI. Итак, вот моя проблема. Я хочу сделать эту службу очень простой в использовании и обойти информацию: к ресурсу следует обращаться из разных точек входа, но это будет противоречить концепции, что каждый «URI обозначает ровно один ресурс»
Нет, это не так ' т. «Каждый палец принадлежит ровно одной руке» не означает, что «у каждой руки ровно один палец». «Каждый URI обозначает ровно один ресурс» не означает, что «каждый ресурс обозначается ровно одним URI».
Тем не менее, перенаправление на канонический URI улучшило бы некоторые варианты использования (например, два пользователя, добавляющие одну и ту же статью в закладки на «вкусно», приехавшие туда по разным запросам).
Похоже, вы также думаете о создании URL-адресов с помощью иерархических шаблонов, а не о REST. Приложения REST используют «гипертекст как движок состояния приложения». Форма URI не имеет значения, важно то, что по нему можно перемещаться из представления, возвращаемого в точке входа приложения. Филдинг разъясняет это в своем блоге API-интерфейсы REST должны управляться гипертекстом в качестве анти-шаблона, вызывающего связь между клиентом и сервером:
API-интерфейс REST не должен определять фиксированные имена ресурсов или иерархии (очевидная взаимосвязь клиента и сервера).