REST API - циркулярные ссылки в нормализованных данных

Question

Я разрабатываю REST API для базы данных, которая содержит информацию о виртуальных машинах и серверах и определенную информацию о них; Установленное программное обеспечение, Диски, хранилище и доступное хранилище и т. Д.

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

Я использую Entity Framework и ASP.NET MVC для сборки API, однако я столкнулся с проблемой, для решения которой у меня нет необходимого опыта. Моя работа с базами данных в прошлом была более прямой и конкретной, я никогда не создавал API и, следовательно, не нуждался в сериализации данных из базы данных раньше.

Проблема, которую я обнаружил, заключается в том, что при сериализации данных, например, в отношениях один ко многим и ко многим ко многим один объект может содержать список связанных объектов, и каждый из них может содержать ссылку на родительский объект. , который затем содержит тот же список снова. Таким образом, при сериализации вы получаете потенциально бесконечную рекурсивную загрузку этих объектов в ваш сериализованный ответ. Как пример:

class Machine {
    int ID;
    string Name;
    List<Software> Software;
}

class SoftwareInstallation
{
    int MachineID;
    int SoftwareID;
}

class Software {
    int ID;
    string Name;
    List<Machines> Machines;
}

Вот отношения многие ко многим. Если я загружу Машину, у нее будет список Программ, у каждого из которых есть список Машин. Я мог бы закончить загрузкой всей базы данных, когда мне нужен только один объект.

Мне интересно, как обычно решить эту проблему в дизайне API. Я не хочу отправлять слишком мало данных для вызова API, иначе у клиента будет слишком много работы, но я также хочу избежать отправки слишком большого или худшего результата, заканчивающегося бесконечным размером ответа. Мне известны такие понятия, как загрузка Lazy и Eager и т. Д., И как вызывать их с помощью Entity Framework, однако я не уверен, когда использовать их, чтобы минимизировать количество требуемых вызовов API и одновременно снизить риски загрузки слишком много.