Когда кто-то моделирует ресурсные отношения, приводится классический пример для articles
и comments
. Это становится простым для моделирования, потому что:
Но как поступить в случае, когда связанный ресурс существует только в контексте родителя?
Например, order
и items
:
В JSON-API объекту отношения нужны «тип» и «идентификатор», чтобы указать связь:
"relationships": {
"links": {
"self": "http://example.com/orders/123/relationships/items",
"related": "http://example.com/orders/123/items"
},
"data": {
"type": <what goes here>,
"id": <what goes here>
}
}
Тип и идентификатор данных должны быть связаны с номером заказа 123. При условии, конечно, что им не присваивается UUID или что-то подобное из базы данных, потому что они, по сути, являются составным ключом. Они существуют в основном как комбинация внешних ключей.
Как с этим справиться?
Один из вариантов отношения — использовать type как order_item
и id как хэш или что-то вроде конкатенации строк с разделителями идентификатора заказа и идентификатора элемента. (например, 123_abc). 123 я получаю из заказа, а abc я получаю из пункта в заказе.
Есть ли другой способ, кроме как полностью избежать необходимости обеспечивать связь ресурсов?
Каждый ресурс должен быть однозначно идентифицирован комбинацией type
и id
в соответствии со спецификацией JSON API:
Identification
Every resource object MUST contain an id member and a type member. The values of the id and type members MUST be strings.
Within a given API, each resource object’s type and id pair MUST identify a single, unique resource. (The set of URIs controlled by a server, or multiple servers acting as one, constitute an API.)
https://jsonapi.org/format/#document-resource-object-identification
Поэтому вам требуется не только идентификатор для связь ресурсов, но и создание любого допустимого ответа, включая такой ресурс.
Но нет никаких правил о том, как вы генерируете эти уникальные идентификаторы для каждого типа. Сочетание уникального идентификатора заказа с уникальным идентификатором элемента для получения уникального идентификатора для каждого элемента в заказе кажется хорошим подходом, если ваша модель данных не включает идентификатор.
@Will Это был бы хороший дополнительный вопрос, но если коротко: если вы хотите обновить отдельные элементы в коллекции, они должны быть представлены как собственные ресурсы, потому что, если они представлены как атрибут, вы можете изменить их все сразу только .
Да, этот вопрос открыт на форуме обсуждения json-api. Спасибо.
Спасибо @jelhan, чем больше я читаю json-api обсуждений, тем больше вижу, что эта концепция рекламируется как центральный принцип. Это начинает становиться интересным, хотя в как каждый решает, что может быть ресурсом. JSON-API/REST, кажется, хочет, чтобы один продвигать связанный ресурс был на верхнем уровне, чтобы сгладить вещи и уменьшить вложенную сложность.