Коллекции ASP.NET REST API
Я пытаюсь создать REST API на основе существующей модели базы данных. У меня уже есть один созданный, но я хочу сделать его проще и понятнее, прежде чем я начну кодировать клиентское приложение. Я решил использовать ASP.NET Core как внутреннюю технологию и внешний интерфейс WPF (также будет интерфейс Angular / Ionic). Модель базы данных очень проста, она содержит около 30 таблиц (разные документы со связанными ресурсами и коллекциями).
Пока что API использует плоский URL - иногда мне приходится размещать / размещать дочерний объект вместе с его родителем. Должен ли я использовать вложенный URL (API / Document / {id} / Item), чтобы упростить отправку объекта, или даже использовать единственный идентификатор, который делает этот объект плоским?
Вторая проблема, с которой я сталкиваюсь, когда мне нужны данные из дочернего объекта для данных, необходимых для источника сетки данных - должен ли я добавить новый метод / контроллер для получения ViewModel со всеми свойствами, необходимыми для сетки данных, или я должен сначала получить коллекцию родительских объектов, а затем получить дочерние объекты и построить представление в клиентском приложении?
Ответы 1
В конечном итоге этот выбор зависит от многих параметров, а также от предпочтений вашей команды.. Вы не дали достаточно подробностей, чтобы дать абсолютный совет, но даже если вы их дали, все равно однозначного ответа может и не быть.
Если вы сомневаетесь, для обеих ваших проблем, я бы порекомендовал выбирайте плоские, простые, полные объекты передачи данных. (Обновлено: конечно, не будет плоским, если у вас есть связанные коллекции, но все же это будет просто и полно)
В этом есть преимущество уменьшение количества подключений / обращений к API, которое имеет некоторые накладные расходы для всей сетевой инфраструктуры, а также для клиента.
Во-вторых, я думаю, что это упрощает разработку (но я признаю, что это спорно)
А также по второй проблеме, помогает разделите проблемы между вашим API и вашим клиентским приложением. Создание модели ViewModel часто необходимо (возможно, вы не хотите раскрывать некоторую информацию по соображениям безопасности или производительности), но не усложняйте ее только для клиентского приложения; вы хотите, чтобы ваш API мог легко использоваться новым клиентом / новой версией позже.
Чтобы показать вам, почему обычно хуже делать много отдельных звонков:
Представьте, что вы хотите получить 40 документов.
Если в каждом документе есть Item1 и Item2, это будет еще 80 вызовов, если вам нужно получить Documents / 1 / Item1, Documents / 1 / Item2 и т. д.!
Кроме того, для вашей фронтенд-разработки вам необходимо управлять обратными вызовами (сначала вызовите документ, как только он будет готов, получите item1 и item2), что кажется более сложным, чем получение всей партии за один раз (поскольку в конечном итоге вам нужно дождаться всего быть там).
Хуже того, возможно, что-то из объекта изменилось, и его дети тоже в промежутке между звонками. Вы можете закончить версией A родительского объекта, но версией B его дочерних элементов!
Конечно, есть некоторые ситуации, которые могут сделать вызовы разложенных дочерних элементов интересными.
Если вам часто требуется получить только элементную часть документа, без необходимости перезагружать весь документ, это будет хорошим аргументом в пользу этого.
Или, если общий документ большой, и вы хотите иметь возможность отображать части загруженных документов до завершения полной загрузки.
Последний недостаток, который я вижу, когда у вас есть связанная коллекция связанных объектов, заключается в том, что у вас может быть много повторений связанных объектов. В этом случае имеет смысл сделать что-то более сложное, если вам нужно избежать слишком большого количества повторений, и иметь несколько отдельных вызовов для основного объекта, отношений и загрузки связанных объектов только один раз, даже если некоторые из них используются несколько раз, может быть полезно.
Я дам такой же ответ: предпочитайте «получить все за один звонок», если у вас нет особой причины не делать этого. Итак, в этом случае, конечно, объект не будет полностью плоским, но будет «самым простым».
@ user5671675 (я отредактировал свой ответ, чтобы прояснить этот момент)
Спасибо за ответ, вы убеждаете меня, что я на правильном пути, но, как говорится в заголовке сообщения, у меня также есть проблема с коллекциями - следует ли сделать родительский объект плоским и получить связанную коллекцию со вторым запросом или в этом случае добавить коллекцию в родительский объект ?