REST - множественный URI для одного и того же ресурса (???)
Я пишу документ о внедрении службы REST для университетских научных работ, и у меня есть небольшая проблема, понимающая взаимосвязь между URI и ресурсами.
В нем говорится, что ресурс может иметь один URI или многие. Итак, вот моя проблема. Я хочу сделать эту услугу очень простой в использовании и обходить информацию: к ресурсу следует обращаться с разных точек входа, но это противоречит концепции, что каждый "URI обозначает ровно один ресурс".
Итак, мой вопрос заключается в следующем: или нет в соответствии с REST следующее:
Я хочу разоблачить информацию об исследовательской публикации (скажем, эксперт).
К этому URI можно получить доступ: УНИВЕРСИТЕТ/публикации/{my_publication}.
Но так как эта статья написана исследователем, который работает на факультете социальных наук, также будет иметь смысл, что публикация имеет этот URI: УНИВЕРСИТЕТ/факультеты/social_science/публикации/{my_publication}.
Кроме того, поскольку служба также раскрывает всех исследователей, работающих в университете (например, УНИВЕРСИТЕТ/исследователи/{my_researcher}), также будет иметь смысл, что публикацию можно назвать УНИВЕРСИТЕТ/исследователи/{my_researcher}/публикации/{my_publication}.
Это может продолжаться с несколькими моментами использования, но вы получаете идею.
Это в соответствии с REST или нет?
Могу ли я сохранить это и решить эту дилемму, отправив код ответа 303 ( "См. также" ) вместе с каноническим URI (это будет УНИВЕРСИТЕТ/публикации/{my_publication}).
Заранее благодарю вас!
Ответы
Ответ 1
В нем говорится, что ресурс может иметь один URI или многие. Итак, вот моя проблема. Я хочу сделать эту услугу очень простой в использовании и обходить информацию: к ресурсу следует обращаться с разных точек входа, но это противоречит концепции, что каждый "URI обозначает ровно один ресурс"
Нет, нет. "Каждый палец принадлежит ровно одной руке" не означает, что "у каждой руки есть ровно один палец". "Каждый URI обозначает ровно один ресурс", не означает, что "каждый ресурс обозначается точно одним URI".
Тем не менее, переадресация на канонический URI улучшит некоторые варианты использования (такие два пользователя, которые закладывают одну и ту же бумагу на вкусные, приехали туда из разных запросов).
Кажется, вы думаете о создании URL-адресов с помощью иерархических шаблонов, а не о REST. Приложения REST используют "гипертекст как механизм состояния приложения". Форма URI не имеет значения, важно то, что она судоходна из представления, возвращаемого в точке входа приложения. Филдинг делает это ясно в своем блоге API REST должен быть основан на гипертексте в качестве анти-шаблона, вызывающего связь между клиентом и сервером:
API REST не должен определять фиксированные имена ресурсов или иерархии (очевидное соединение клиента и сервера).
Ответ 2
Это часто обсуждаемая тема, и я считаю, что путаница основана на попытке понять, что на самом деле указывает 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 относятся к двум различным RESOURCES, потому что оба возвращают 200. Однако, когда вы используете согласование контента на http://www.example.org/myresource, вы можете получить два разных представления одного и того же ресурса.
Ответ 3
Хотя каждый ресурс публикации должен иметь одно и только одно имя ресурса (URI), вы можете создавать ресурсы, которые являются запросами, и которые возвращают списки других имен ресурсов.
У вас может быть UNIVERSITY/publication/{publication} как шаблон имени ресурса для ресурсов публикации, а UNIVERSITY/faculties/{faculty}/publications - шаблон для присвоения имен ресурсам, которые являются списками публикаций для определенных факультетов. Аналогично UNIVERSITY/researchers/{researcher}/publications может быть шаблоном имен ресурсов для списков публикаций, созданных определенным человеком.
Ответ 4
В нем говорится, что ресурс может иметь один URI или многие. Итак, вот моя проблема. Я хочу сделать эту услугу очень простой в использовании и обойти информацию: к ресурсу следует обращаться с разных точек входа, но это противоречит концепции, что каждый "URI обозначает только один ресурс".
Я не думаю, что здесь есть какое-то противоречие. URI может указывать не более одного ресурса, но многие URI могут указывать на один и тот же ресурс. Многозначная связь между URI и ресурсами, если хотите.
Тем не менее, я бы не слишком волновался о том, является ли ваше приложение RESTful или нет. Это просто принцип дизайна. Вот хорошая статья того парня, который утверждает, что REST на самом деле не предназначен для людей с веб-браузерами: http://starkravingcoder.blogspot.com/2009/01/where-are-rest-frameworks.html
Ответ 5
+1 Джим Ферранс.
Кроме того, наличие всего одного URI на ресурс упростит создание ссылок на вашем сайте. Я прочитал, что поисковые системы предпочитают, чтобы контент не повторялся и в разных URI.
Ответ 6
Вам нужно увидеть разницу между ресурсом и сущностью, которую он представляет.
Рой Филдинг пишет в своей диссертации, раздел 5.2.1.1:
Ресурс - это концептуальное сопоставление с набором объектов, а не объект, который соответствует отображению в любой конкретной точке в время.
Поскольку все ваши ресурсы несут немного другую семантику, ее можно считать RESTful, это мое мнение. В зависимости от структуры вашего типа медиа вы можете использовать отношение канонических ссылок, чтобы указать "предпочтительный uri".
