⚡ Kotobotov ⚡

дополнительно шифровать токен достаточно бессмысленная вещь - тк он уже представляет из себя зашифрованные данные.
Если требуется бОльшая безопасность у токена записывают короткое время жизни и требуют регулярно его обновлять (например каждый час), используя еще один токен)

при хранении в файловой системе, у вас будет запрос к данным и еще один запрос к файловой системе (в зависимости от характеристик диска, это добавляет к запросу до 8 миллисекунд в случае с жесткими дисками)
в случае хранения фотографии вместе с запрашиваемыми данными, в самой БД у вас не будет этого лишнего запроса, а данные все равно читаются пакетно большим объемом, так что это только плюс к скорости.

абсолютно бесполезные комментарии,
любой нормальный разработчик понимает что такой key, value, delete, clear, get -> писать каждый раз что это такое это извращение.
также извращение использовать сокращения -> пишите код понятно, тогда и комментарии не нужны, чем писать комманду del или D , а потом указывать что это delete
в эпоху автокомплитов, сокращения абсолютно бесполезны, и только ухудшают восприятие.
опишите что вы ожидаете на входе, и какой результат от работы хотите получить, на этом можно остановиться -> комментарии по коду делайте если только что-то там действительно хитрое происходит, или потенциально например слабые места, в которых вы не уверены (например у вас указанно про бесконечную рекурсию, это полезно). остальное не нужно, остальное должно быть понятно из самого кода, понятных названий переменных функций и тд.

у вас в любом случае бэкенд и фронтэнд разделён, вы их так-то даже на разных языках пишете).
можно рендерить ответ на сервере, можно разработать приложение которое бы данные грузило и создавало внешний вид уже на клиенте.
Но нужно понимать что тогда человеку чтоб увидеть ответ, нужно в начале загрузить это приложение.
Оба подхода имеют место быть.
отдавать на запросы уже готовый HTML это тоже стоящая вещь, позволяет быстро сформировать простую страницу.
В твиттере например рендерят всё на серевере, тк считают что такой способ для их сервиса больше подходит.
Хотя я за внедрение SPA приложений (одностраничные приложения) - это позволяет не только снизить нагрузку на сервера, переложив часть работы на клиента, но и сделать более продвинутые интерфейсы, с гладкой плавной подзагрузкой данных. Ну и да для масштабирования сервиса возможность отделять части приложения не заботясь о сборке на сервере, крайне полезна.

эта информация уже идёт в заголовке запроса, они её оттуда считывают (HTTP_Referer)