Точь в точь ли маппятся поля json-сущности на поля в таблицах базы данных?
Опишу проблему: я не совсем понимаю связь между json-сущностями которые отгружаются rest-методом и таблицами в базе данных.
Вот говорят: в rest-api сущность отгружается полностью. Окей. Дергаем Postman'ом get-запрос (или DevTools -> Network -> XHR) и смотрим данные. Приходят объекты где есть ключ и значение. Каждый ли ключ обязательно должен маппится с полем в какой-то таблице?
Казалось бы - да? Сразу отмечу: тип данных jsonb в бд не рассматриваю - я знаю, что можно json запихнуть хоть в одно поле. Это частный случай. У меня вопрос про общую практику. Итак, казалось бы - да. Один ключ-поле = одно поле в бд. Но ведь это же не безопасно. Так любой может открыть devtools и посмотреть что отгружается и прикинуть как устроена база данных.
И реальная ситуация, которую я вижу, она иная. Я открываю таблицу и вижу там много разных полей. А в сущности, которая отгрузилась, данных меньше. При этом в этой таблице есть значения из json-сущности: вот uuid, вот текстовка, вот дата, вот статус с булевым типом...
Моя гипотеза следующая:
Json-сущность отгружающаяся через Postman или devtools не равна сущности в базе данных. Это означает что не все поля в json-сущности маппятся на соответствующие им поля в таблицах в бд.
Так что же тогда нужно понимать под фразой "сущность отгружается полностью"?
То же самое и с post/put/patch запросами. Передаем несколько параметров, но обновлений в базе существенно больше. Вот говорят: put обновляет сущность целиком. А кто-то говорит: put обновляет таблицы в бд целиком. Что есть правда?
Мне все это надо чтобы лучше понимать rest-api интерфейс. Я вижу методы в Swagger, вижу передаваемые в них поля и значения, но в базе данных вижу что нет маппинга каких-то полей.
Понимаю, в идеале, чтобы понять, мне надо самому запрограммировать тестовый rest api интерфейс и настроить запись и чтение в бд. Тогда сразу все в голове встанет на свои места. Но я не умею программировать rest-интерфейсы.
На всякий случай отмечу: я знаю, что "одна таблица не равно одна сущность". Сущность может быть раскидана по нескольким таблицам. Мой вопрос больше про маппинг полей в json-объектах отгружаемых Postman/Devtools и полями в таблицах бд.
Сейчас объясню что я имею ввиду: возьмем например GraphQL, он позволяет отгружать только то, что необходимо, а REST API так не умеет, там сущность отгружается полностью. Поправьте, меня, пожалуйста, если я не прав.
Не припомню чтобы Postman/Devtools как-то относились к базам данных.
Я упомянул Postman и Devtools как те инструменты с помощь которых я смотрю json-сущности методов. Извиняюсь если эта была лишняя информация и она ввела в заблуждение.
REST API так не умеет, там сущность отгружается полностью. Поправьте, меня, пожалуйста, если я не прав.
pavel_the_man, я видел много rest api, где параметрами можно влиять на вывод. Добавляешь в запрос, условно, extended_info=1 и получаешь чуть более подробный ответ. Или при генерации какого-либо отчёта передаешь список интересующих полей и отчёт содержит только их. Концептуально то же самое, только graphql более гибкий.
А так есть какой-то "максимальный" объект, который может вернуть хоть rest api, хоть graphql, и есть возможность его фильтровать входящими параметрами. И вот этот объект - он не обязан повторять структуру какой-либо таблицы в базе. Может даже вообще никакой связи с базой не иметь.
Хотя никто не мешает мапить поля в базе на api ответ один к одному, но это плохая практика, так как жизненный цикл базы и api различен.
База может и будет эволюционировать, менять свою структуру по мере развития проекта.
А вот api должно быть стабильным. Клиентам вряд ли понравится каждый раз переделывать интергацию с вашим api каждый раз как на вашу базу будет накачена миграция.
alexalexes, главное, она отлично передаёт мои собственные ощущения! Кажется что вот-вот, ещё чуть чуть, и всё встанет на свои места! А получается наоборот, только хуже и хуже )))
Простой
