API-интерфейс REST. Получение и сохранение дочерних записей

Я разрабатываю API для отдыха, и у меня есть некоторые сомнения по поводу разоблачения и потребления детей из отношения. Предполагая, что у меня есть объект A с отношением один ко многим к объекту B (поэтому A может иметь несколько прикрепленных B), и я разрабатываю конечную точку для создания объекта A, а DTO для объекта A включает список для объекта B, и пользователь предоставляет действительный , его тоже надо сохранить?

Пример. Отправка публикации в какую-либо конечную точку, например. /апи/v1/как

{
    entityAfield1: someValue,
    entityAfield2: someOtherValue
    Bs: [
        {
            HERE a valid B payload
        }
    ]
}

должен ли я также сохранить B и создать связь между A и B? Что, если у Б тоже есть дети? Его тоже надо сохранить? Или я должен просто сохранить A и создать конечную точку, например

/api/v1/As/{Aid}/Bs/{Bid}

создать отношения? И тот же вопрос о получении данных. Должен ли get всегда извлекать всех детей? Внятного ответа на этот вопрос в сети я не нашел.


rest restful-architecture
person Strk89    schedule 08.05.2018    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Проблема может быть решена путем возврата идентификаторов B. Таким образом, пользователь услуги решит, следует ли извлекать фактические данные связанных ресурсов.

Чтобы взаимодействовать с такими конечными точками, как это

/api/v1/Bs/{Bid}

можно использовать, а также более подробный

/api/v1/As/{Aid}/Bs/{Bid}

однако слишком вложенные конечные точки, такие как

/api/v1/As/{Aid}/Bs/{Bid}/Cs/{Cid}/Ds/{Did}

следует избегать и, скорее всего, указывает на недостаток конструкции.

Для древовидной структуры или отношений «многие ко многим» в целом должен быть представлен промежуточный ресурс, представляющий связь. Существует хороший пример реализации REST API от Google, его "дочерние" раздел был бы особенно полезен для такого случая.

person Pavel    schedule 10.05.2018