REST - несколько URI для одного и того же ресурса (???)

Question

Я пишу статью о внедрении службы REST для исследовательских работ университета, и у меня возникла небольшая проблема с пониманием взаимосвязи между URI и ресурсами.

В нем говорится, что ресурс может иметь один или несколько URI. Итак, вот моя проблема. Я хочу сделать этот сервис очень простым в использовании и обойти информацию: доступ к ресурсу должен осуществляться с разных точек входа, но это будет противоречить идее, что каждый «URI обозначает ровно один ресурс».

Таким образом, мой вопрос заключается в том, соответствует ли следующее или не соответствует REST следующее:

Я хочу предоставить информацию об исследовательской публикации (скажем, рецензируемой).

Доступ к этому URI возможен: UNIVERSITY / публикации / {my_publication} .

Но так как эта статья написана исследователем, который работает, скажем, на факультете социальных наук, будет также иметь смысл, что публикация имеет такой URI: УНИВЕРСИТЕТ / факультеты / social_science / публикации / {my_publication} .

Более того, поскольку служба также предоставляет информацию обо всех исследователях, работающих в университете (например, UNIVERSITY / research / {my_researcher}), также будет иметь смысл, что публикацию можно назвать UNIVERSITY / investors / {my_researcher} / публикации / {my_publication} .

Это может продолжаться с несколькими вариантами использования, но вы поняли идею.

Это соответствует REST или нет?

Могу ли я сохранить это и решить дилемму, отправив код ответа 303 («См. Также») вместе с каноническим URI (это будет UNIVERSITY / публикации / {my_publication}).

Заранее спасибо!

Answer 1

В нем говорится, что ресурс может иметь один или несколько URI. Итак, вот моя проблема. Я хочу сделать эту услугу очень простой в использовании и обойти информацию: доступ к ресурсу должен осуществляться с разных точек входа, но это будет противоречить концепции, что каждый «URI обозначает ровно один ресурс»

Нет, это не так. «Каждый палец принадлежит только одной руке» не означает, что «каждая рука имеет ровно один палец». «Каждый URI обозначает ровно один ресурс», не означает, что «каждый ресурс обозначен ровно одним URI».

Тем не менее, перенаправление на канонический URI улучшило бы некоторые варианты использования (например, два пользователя, добавившие одну и ту же статью в закладки на вкусный, приехав туда с разных запросов).

Вы также, похоже, думаете о создании URL-адресов с помощью иерархических шаблонов, а не о REST. Приложения REST используют «гипертекст как движок состояния приложения». Форма URI не имеет значения, важно то, что он является навигационным по представлению, возвращенному в точке входа приложения. Филдинг поясняет это в своем блоге API-интерфейсы REST должны управляться гипертекстом в качестве анти-паттерна, вызывающего связь между клиентом и сервером:

API REST не должен определять фиксированные имена ресурсов или иерархии (очевидная связь клиента и сервера).

Answer 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 ссылаются на два разных ресурса, поскольку оба возвращают 200. Однако, когда вы используете согласование содержимого на http://www.example.org/myresource, вы можете получить два разных представления одного и того же ресурса.

Answer 3

Хотя каждый ресурс публикации должен иметь одно и только одно имя ресурса (URI), вы можете создавать ресурсы, которые запрашивают и возвращают списки других имен ресурсов.

Вы можете иметь UNIVERSITY/publication/{publication} в качестве шаблона имени ресурса для ресурсов публикации и UNIVERSITY/faculties/{faculty}/publications в качестве шаблона для именования ресурсов, которые являются списками публикаций для определенных факультетов. Аналогичным образом UNIVERSITY/researchers/{researcher}/publications может быть шаблоном имени ресурса для списков публикаций, созданных конкретным человеком.

Answer 4

Вам необходимо увидеть разницу между ресурсом и сущностью, которую он представляет. Рой Филдинг пишет в своей диссертации, раздел 5.2.1.1 :

Ресурс - это концептуальное отображение набора сущностей, а не объект, который соответствует отображению в любой конкретной точке время.

Поскольку все ваши ресурсы несут немного другую семантику, это может считаться RESTful, по моему мнению. В зависимости от структуры вашего типа мультимедиа вы можете использовать каноническое отношение ссылок для указания «предпочтительного uri».

Answer 5

+ 1 Джиму Феррансу.

Кроме того, наличие ровно одного URI на ресурс облегчит создание ссылок на вашем сайте. Я читал, что поисковые системы предпочитают, чтобы контент не повторялся и при разных URI.

Answer 6

В нем говорится, что ресурс может иметь один или несколько URI. Итак, вот моя проблема. Я хочу сделать эту услугу очень простой в использовании и обойти информацию: доступ к ресурсу должен осуществляться с разных точек входа, но это противоречит идее, что каждый «URI обозначает ровно один ресурс».

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

Тем не менее, я бы не стал слишком волноваться по поводу того, является ли ваше приложение RESTful или нет. Это просто принцип дизайна. Вот хорошая статья парня, который утверждает, что REST на самом деле не предназначен для людей с веб-браузерами: http://starkravingcoder.blogspot.com/2009/01/where-are-rest-frameworks.html