[laimas]

Согласен, уже понял это.

Хорошо, если так. Я ведь не настаиваю, я просто сужу по данным от сервера. А сервер, судя по ним, получает данные из MySQL причем версии ниже 5.6. Это я сужу по "2020-06-10 14:06:35.6000000", так как такое может вернуть поле типа TIMESTAMP со значением по умолчанию CURRENT_TIMESTAMP (текущая дата/время как метка времени), поэтому и .6000000 в конце, и только этот тип может иметь такое значение по умолчанию. Зачем в таком формате сервер возвращает я не знаю, можно было бы и вернуть как метку времени (в примере это делает клиент) или удобочитаемую дату/время. А в версии MySQL 5.6 и выше такое значение по умолчанию может иметь и поле типа DATETIME, этот тип отличается от TIMESTAMP, он не зависит от часового пояса и в базе будет храниться как "2020-06-10 14:06:35".

В MySQL по умолчанию так же нет разницы в каком регистре что написано, можно что-то искать в одном регистре и получить два одинаковых значения в разных. Такой же финт можно сотворить и при выводе, и в итоге у вас могут появится дубликаты. А вот id значение в базе формируются полем с автоикрементом, ранее использованные значения никогда не используются и данные этого поля служат гарантией уникальности (в пределах типа поля, то есть его размера).

А если судить по этому:

"user": {
                "id": 1,
                "username": "Viktor",
                "phone": "111"
            }

то это уже результат обработки серверным скриптом запроса к базе, ибо сама база такого никак не вернет, если только это не дубликаты json-записей в базе (а это тогда не база, а хлам), или очень не поизголяться с запросом. В общем как ни крути, но мягко говоря, сервер возвращает клиенту хлам, пусть он там сам разбирается, что плохо, и надо не клиенту это делать, а править либо запрос к базе, либо скрипт сервера.