REST api desing. Получение и сохранение дочерних записей - PullRequest
Новая
       16

REST api desing. Получение и сохранение дочерних записей

0 голосов
/ 08 мая 2018

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

Пример: Выполнение публикации в какой-либо конечной точке, например / API / v1 / В 

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

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

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

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

1 Ответ

0 голосов
/ 10 мая 2018

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

Для взаимодействия с конечной точкой, подобной этой 

/api/v1/Bs/{Bid}
Можно использовать

, а также более подробный 

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

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

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

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

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

...