Связи отношений в представлениях JSON
Я разрабатываю RESTful API на основе представлений JSON. Чтобы соответствовать HATEOAS, я широко использую ссылки между ресурсами. Поэтому я последовал за этим предложением для сериализации ссылок, очень похожих на ссылки ATOM.
Теперь у меня иногда возникают проблемы с определением правильного типа отношения ссылки. Когда ресурс содержит ссылку на себя, отношение self
очевидно. Он становится более сложным, когда ресурсы представляют собой коллекции и агрегации под-ресурсов или содержат много ссылок на связанные ресурсы.
Возьмите сообщение в блоге в качестве примера и подумайте о ресурсе, который возвращает моментальный снимок блога, включая автора, теги и комментарии этого сообщения в блоге.
Очевидно, что этот ресурс содержит много подресурсов и, разумеется, также предоставляет отдельные ссылки на них:
Пример ресурса:
{
"blogpost":{
"link":{
"rel":"self",
"href":"http://blog/post/4711"
},
"author":{
"name":"Bob",
"link":{
"rel":"???",
"href":"http://author/uri"
}
},
"title":"foobar",
"content":"A long article here…",
"comments":[
{
"comment":"great article",
"link":{
"rel":"???",
"href":"http://blog/post/4711/comment/1"
},
"author":{
"name":"John Doe",
"link":{
"rel":"???",
"href":"http://author/uri"
}
}
}
],
"tags":[
{
"value":"foo",
"link":{
"rel":"???",
"href":"http://blog/post/4711/tag/foo"
}
}
]
}
}
Итак, каковы подходящие отношения для данных ссылок? Я знаю, что существуют типы отношений, такие как tag
, но не все мои ресурсы соответствуют существующим типам отношений. Или можно использовать self
при обращении к автору/тегу/комментарию, потому что он относится к контексту охватывающего объекта JSON (sub-)? Что такое семантический объект self
относится к?
RFC 5988 заявляет:
Контекстом ссылки является либо IRI подачи, либо идентификатор записи, в зависимости от того, где он отображается.
Как я могу интерпретировать это с точки зрения JSON? Является ли каждый новый объект {…}
новым контекстом?
Спасибо!
Ответы
Ответ 1
Это отличный вопрос. Если вы посмотрите на пример Hal, вы увидите, что rels определены в контексте под-ресурса.
Я не знаю ни одного окончательного руководства о том, когда rel относится к ресурсу в целом или к содержащемуся ресурсу.
Единственной дополнительной информацией, которую я могу вам указать, является параметр привязки в RFC5988, который позволяет вам переопределить IRI контекста, используя либо фрагмент, либо полностью новый URI.
В идеале, ваш медиатип должен указывать, отличается ли IRI контекста для вложенных ресурсов, или нужно ли явно изменять IRI контекста. Это было бы еще одним преимуществом использования медиа-типа, такого как application/vnd.hal + json, вместо обычного старого приложения /json, поскольку состояние Hal указывает:
@rel - для определения того, как целевой URI относится к теме Ресурс'. Объектный ресурс является ближайшим родительским ресурсом элемент.
Ответ 2
LSON-LD
Возможно, вы можете взглянуть на JSON-LD (Обозначение объекта JavaScript для Связанные данные. Это выглядит более сложным, чем HAL, но вы можете сделать больше с ним.
JSON-LD стандартизируется внутри W3C, вот рекомендация по предложению.
Кроме
Извините, у меня нет времени, чтобы привести пример.
Ответ 3
Немного поздно ответить на этот вопрос, но для будущей справки я решаю эту проблему:
{
"blogpost":{
"title":"foobar",
"content":"A long article here…",
"link":{
"rel":"self",
"href":"http://blog/post/4711"
},
"link":{
"rel": "author",
"href": "http://author/uri",
"alt":"Bob"
},
"link":{
"rel": "comment",
"alt": "great article",
"href":"http://blog/post/4711/comment/1"
},
"link": {
"rel":"tag",
"href":"http://blog/post/4711/tag/foo",
"alt":"foo"
}
}
}
когда вы думаете об этом, комментарии, теги и т.д. - все разные ресурсы, связанные с вашим сообщением... почему бы потом не сделать их такими, какие они есть.. ссылки! Вы даже сохраняете размер вашего ответа;)