rPman

докину варианты, в linux есть проект fuse, позволяет монтировать файловые системы, описываемые простой библиотекой, работающей как обычное приложение в userspace, на основе его сделана поддержка всяких экзотических ситуаций, в т.ч. работа по ftp - ftpfs (идет штатно с любым линукс), так же есть sshfs для доступа по ssh, avfs для архивов (сюда же fuse-zip и archivemount) или экзотический winregfs для чтения файлов реестра windows как файлы и т.п. десятки библиотек идут по дефолту в репозитории.

монтируешь в каталог без root и пользуешься как локальными файлами из любых программ

Все зависит от целей - для себя (если ты разработчик или занимаешься внедрением кем то написанного) и своего успокоения или для отчетности и сертификации.

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

Если второе - то все будет зависеть от требований этой отчетности, и там способ проведения аудита будет определяться наличием и доступностью компаний под эти требования.

Мне надо проверить что запрос несет в себе json и определенный header, что бы ни кто просто так не мог запросы кидать

исторически это делают через авторизацию

Добавить basic auth либо на стороне веб сервера либо прямо в php дело нескольких строчек. Для отправки запроса практически любой библиотекой можно пользоваться следующим форматом url - http://user:password@site.com/path (даже php file_get_contents поддерживает)

Ну и самое простое - по токену
токен это буквально пароль, который либо прописан в конфигах/исходниках твоего сервиса либо выдается сервисом авторизации на время. Этот токен можно указывать либо в заголовках (тогда для отправки запроса нужно этот заголовок установить или еще проще - разместить этот токен прямо в запросе, т.е. site.com/doit?auth=secret_password

Если протокол общения с твоим сервером будет https никто не сможет узнать ни логин пароль, ни токен авторизации, не имея доступа к машине с которой они вызываются

наверное нельзя в sqlite внутри запроса ; использовать?
если тебе надо ускорить вставку, используй транзакции, перед вставкой кучи строк $PDO->beginTransaction() а после соответственно $PDO->commit();

Если же действительно надо именно одним запросом несколько insert, попробуй вместо кучи insert написать один, вставляющий результат следующего селекта, а он уже в свою очередь собирай с помощью union all селекты с константами::

INSERT INTO table (idGame, idChannel, dateU)
SELECT :iG1, :iC1, :dU1
UNION ALL
SELECT :iG2, :iC2, :dU2

Кучи if ($request->input("type") заменяй на switch case, тем более далее по тексту у тебя оно используется, пиши код хотя бы в одном стиле.

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

Про права доступа, у тебя точно 2 состояния - public и authorized? может у тебя еще есть какой-нибудь superuser? или еще есть права на основе данных (например если статус операции 'такой то' то действие запрещено)... хотя метод по любому должен быть ->allowed() который собирает данные по текущему пользователю, состоянию, данным и т.п. хотя лучше разделять права доступа по роли и по состоянию, пусть будет пара методов.

Вот такие строчки "required|numeric|min:1|max:10000" - bad practics, магические константы, что значит 10к, 15, 3, 24, 5000... везде разные, что почему зачем, уже через пол года ты не вспомнишь а уж другой программист и подавно не поймет. Оформляй в виде функции-генератора или даже класса, документируй все значения, даже если это значения от балды, когда ты их выдумывал какой то смысл ты в это вкладывал - опиши это в коментариях в этой функции или классе, не обязательно все выносить в конфиг файл, сам отдельно лежащий файл с таким классом уже этот конфиг. Мало того, почему сериализация массива такая странная, на рынке существует уже безоговорочный стандарт json, и machine и human readable, накладные расходы минимальны (можно заставить паковать nginx, по трафику будет не на много больше чем умно оформленный protobuf), тем более у тебя там ошибки уже в json выдаются.

есть только числа и нужна их сумма? нет скобок или вызова функций например?

$str='200 - 100 - 50 ';
if(preg_match_all('/\s*([+-]?)\s*(\d+)/',$str,$m))
{
	$sum=0;
	foreach($m[0] as $i=>$v)
		$sum+=($m[1][$i]=='-'?-1:1)*$m[2][$i];
	echo 'Сумма: '.$sum;
} else
{
	echo 'Синтаксическая ошибка';
}

решение не фонтан, кучу ошибок тупо проигнорирует и ты об этом даже не узнаешь

Если цель - уменьшить трафик, то сжатием пусть занимается веб сервер, собственно так и есть по умолчанию, все происходит прозрачно для пользователя.

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

Ну и в догонку, указанный код слегка повысит нагрузку на процессор, незначительно но все же.

Отвечу максимально полно

Чтобы скрипт php что то 'получил', он должен быть как минимум запущен, подавляющее большинство стратегий создания приложений на php это когда клиент (браузер) либо чистый html либо javascript делает запрос на сервер, а сервер запускает на короткое время php скрипт чтобы тот вернул ответ (готовый html или данные в каком то виде, например json чтобы javascript обработал)

Общение между браузером и сервером происходит по http короткими запросами вопрос-ответ, поэтому фраза 'установить переменную' немного некорректна в этом случае, ведь установив переменную в результате запроса, таковой она будет только тот короткий момент, пока этот запрос обрабатывается (например все что идет в http запросе как GET или POST параметры, веб сервер автоматически прописывает в глобальные переменные $_GET и $_POST соответственно, бери и читай). Для отправки запросов из браузера на сервер есть готовые библиотеки, гуглить ajax (на чистом javascript без библиотек для этого можно использовать XMLHttpRequest)

Поэтому есть способ передачи данных через заголовки запроса, с помощью cookies, браузер устанавливает куки, которые автоматически в дальнейшем добавляются к любому запросу с данного домена на сервер. На сервере в php доступ к ним можно получить из переменной $_COOKIE. Так же есть способ установить куки со стороны сервера. С точки зрения эффективности это не самый лучший способ, так как данные получаются не сохраняются где то на сервере, а транслируются повторно с каждым запросом, поэтому большие объемы хранить там не рекомендуется.

Существует подход, когда php приложение не короткоживущий скрипт а сам веб сервер, обработка запросов, чтение get/post параметров, куки и прочее, в этом случае обрабатывает это приложение (есть библиотеки, например асинхронный php react), но зато, так как приложение не завершает свою работу после запроса, прочитав переменную из запроса ее можно сохранить в памяти приложения. Этот подход на порядок ускоряет работу приложений по сравнению с классическим http-rest подходом (ведь скриптам не нужно на каждый запрос восстанавливать состояние серверного приложения, загружая нужные данные откуда-то, например из базы данных) т.е. из коробки более быстрый но сложнее к масштабированию.

В качестве бонуса у этого подхода появляется удобная возможность использовать websocket, когда запросы отправляются не в виде отдельных а как пакет данных внутри уже открытого соединения (если что веб серверы и браузеры поддерживают и для типичного http rest незакрываемые соединения, но они заголовки так или иначе передаются, занимая время и ресурсы), и не только клиентское приложение сможет отправлять запросы от браузера на сервер но и сервер сможет слать сообщения клиенту

читай заголовки и ищи Content-Disposition

Заголовки парсить вручную, добавив их в вывод curl_setopt($ch, CURLOPT_HEADER, 1);
заголовки в текстовом виде, по строке на заголовок (разделитель \r\n), между именем и значением разделитель ': '

p.s. если content-disposition нет, то имя файла исторически берут из url, отсекая все до конца начиная с ? и до первого '/' если читать с конца (никто не гарантирует что там будет желаемое в принципе)

gethostbyname