Проектирование API во избежание использования нескольких сериализаторов моделей (DRF)
Я разрабатываю свой бэкенд с помощью Django и свой API с помощью DjangoRestFramework.
Дело в том, что мне интересно, как работать с сериализаторами, чтобы не иметь их тонны для одной модели.
Рассматривается модель, которая представляет, скажем, InventoryItem (например, компьютер). Этот компьютер может быть связан с категорией, поставщиком, компанией, контактом в этой компании...
Это заставляет отношения быть сериализованными и вносит вложенные данные в возвращаемый элемент. В то время как мне могут понадобиться все эти поля в представлении списка, я могу не нуждаться в них в представлении формы или в представлении канбан. И если я хочу, например, в представлении формы заявки в службу поддержки иметь компонент ввода с автозаполнением, чтобы связать заявку с этой инвентарной позицией, я хочу иметь только, скажем, имя инвентарной позиции, поэтому возвращение списка позиций со всеми вложенными данными будет немного излишним, поскольку мне нужно только ее имя.
А вы можете сказать:
Просто сделайте разные сериализаторы для нужных вам сценариев.
В итоге получилось бы что-то вроде :
- InventoryItemFormSerializer
- InventoryItemListSerializer
- InventoryItemInputSerializer (используется для компонентов ввода)
Также для листинга элементов я бы использовал конечную точку .../api/inventory/items с InventoryItemListSerializer, но для заполнения компонента ввода я бы использовал ту же конечную точку, чтобы не дублировать конечные точки. Это означает, что я должен сделать какую-то "магию", чтобы заставить пользователя использовать тот или иной сериализатор?
- Как мы должны проектировать конечные точки/сериализаторы, чтобы не предоставлять слишком много данных и избежать дублирования конечных точек ?
Я думал о том, чтобы иметь вложенный сериализатор и основной для модели "each" (когда это необходимо) и сказать "неважно", если у меня будет слишком много полей в сериализованных данных. Но это кажется немного ограничивающим...
Заранее спасибо за советы.