Когда мы проектируем JSON для API запросов или ответов, важно понимать, что
он не берётся «с потолка». У него всегда есть два ориентира 👇
1️⃣ База данных (БД) — источник данных
👉 Показывает, какие параметры физически хранятся в системе
👉 У каждого JSON-объекта есть ключевая таблица (основной объект) и связанные таблицы (доп. инфо).
Часто именно связанные таблицы в БД подсказывают структуру JSON:
• один-к-одному → вложенный объект {}
• один-ко-многим → массив объектов []
👉 Названия полей в БД помогают сделать названия в JSON, но не обязательно совпадают.
👉 Не все поля из БД попадают в JSON.
👉 А иногда наоборот — в JSON нужны поля, которых ещё нет в БД. Это повод доработать модель данных.
2️⃣ Клиент API — интерфейс (UI) или другая система
👉 Подсказывает, какие параметры надо включить в JSON.
👉 Именно от потребностей клиента в первую очередь зависит, что будет в JSON.
Если вы работаете над API для приложения с UI — смотрите на макет и проектируйте JSON от потребностей UI.
Если работаете над API для внешней интеграции — смотрите на требования разработчиков внешней системы.
👉 Клиенту обычно нужны от JSON как бизнес-данные, так и технические параметры (например, id, ссылки, и др)
👉 Форматы данных в JSON могут отличаться от того, как они представлены на UI (пример: дата и время)
👉 Не все поля JSON отображаются на UI. Главное, чтобы клиент получил всё, что ему нужно.
📌 Итого: JSON проектируется не от БД и не от UI, а между ними.
Мы соединяем:
• то, что можем взять из БД
• с тем, что нужно отдать клиенту
и формируем структуру, понятную и полезную для клиента API.
------------
📸 На картинке к посту — пример JSON-ответа для метода:
GET /events/{eventId} - метод получения данных о событии в календаре
Разберите его по частям:
• какие поля есть в JSON и как они связаны с UI?
• что есть в JSON по сравнению с БД, а чего нет?
🌐 Полезные по проекту:
БД MeetsGA
Дизайн в Figma для MeetsGA
Запоминайте логику 🤝
------------
#RestApiGA