Vitsliputsli

Контроллер, представление, модель - это элементы MVC, к ООП отношения не имеют.
Контроллер получает от пользователя запрос в определенном виде (запрос браузера, обращение к API, команда, все это разные группы контроллеров). Распарсив запрос передает его в модель для обработки.
Модель содержит бизнес-логику, т.е. по-сути то, что должно делать ваше приложение, без привязки к способам обращения пользователей и способам вывода. Возможно будут вызываться модели работающие с БД, а может и не будут, это неважно, не превозносите БД как сверхсущность, это обычный инструмент, один из множества.
Далее модель передает подготовленные для вывода данные в контроллер (в классической MVC сразу в представление), и контроллер передает их в нужное представление.
Вот и все, простая схема, которая позволит отделить мух от котлет, создавать API, видоизменять вывод, не трогая основную логику. А работа с БД, совсем другой вопрос.

Вы хотите странного. Не нравится pretty url, не используйте его, в оригинальном виде контроллер/экшен задаются параметром в адресе. Но зачем изобретать свой роутинг при использовании фреймворка?
И, обычно, когда говорят о rest, подразумевают одну из моделей Ричардсона, т.е. использование http-методов, в данном случае post или put.

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

А какова разница? В цифрах.
Post обычно подразумевает отправку данных в теле, а get в адресе. В принципе на размер запроса это не особо влияло бы, но обычно данные шлют в формате form-data, и используют громадные разделители, поэтому запрос в лёгкую может вырасти раза в 2 по сравнению с get. Второй момент, на другой стороне это все нужно ещё распарсить. Но, конечно, совсем не обязательно данные передавать как form-data.
Т.е. теоретически - да, post медленней, практически - не думаю, что эта разница сколько-нибудь существенна. И как правильно заметили, адрес не предназначен для передачи конфиденциальных данных, т.к. попадает в логи.

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

Перепишите ваши условия так, чтобы не требовалось их прерывать на полпути. То что вы хотите очень сильно ухудшает читаемость, поэтому оператор goto крайне не рекомендуют к использованию, а это тоже самое.

Ratchet

Если нет нужды писать эксепшен для не float в запросе, тогда преобразуйте так:
$var = (float)strtr($input, ',', '.');
Если нужно, то конвертните обратно в string и сравните.
Имхо, это нагляднее и очевиднее, чем регулярка.

Если у вас "четкое" разделение на фронт и бэк, значит, по сути у вас 2 технических проекта, взаимодействующих между собой. И у них не может быть одной и той же задачи, т.к. делают они разное.
Судя по остальному тексту, вы не декомпозируете задачи, отсюда и такие вопросы. Тогда, у вас 2 варианта, начать декомпозировать задачи на отдельные подзадачи, где будет отдельный исполнитель, можно прикинуть трудозатраты, указывать зависимости и т.п. К тому же, в redmine из коробки можно строить древовидную структуру задач. Тогда у вас появится хоть какой-то контроль и вы сможете планировать. Либо не заморачиваться, т.к. 1 или 2 задачи на ситуацию не повлияют, и пусть разработчики сами делят задачи и планируют.

А что вы теряете? Боитесь, что возьмут, а вы не вытяните? Не парьтесь за них, придите и расскажите, что знаете. Не нужно говорить, что ничего не знаете, говорите о том, что реально делали, пусть и несложные вещи. Пусть они уже решают сами, быть может им и нужен начинающий специалист, которого они подготовят под себя, и который, быть может, не требует сотни денег. В любом случае, это бесценный опыт для вас.

PDO лучше только в плане универсальности (драйвера, а не вашей работы, это не ORM), mysqli как специализированный драйвер к примеру более производителен (несущественно). Защиту от sql инъекций вам дадут только подготовленные запросы, где вы их будете применять, в pdo или mysqli, без разницы.
Но все современные orm и просто обертки пишутся для PDO. Про mysqli забыли. Нативная работа с mysqli ужасна, т.к. очень устарела, эксепшены отсутствуют, да и порой просто не очень адекватна.

Он цепляет файл по пути из include_path. Почему раньше работало можете знать только вы, может include_path был другой, может HTML/Common.php там существовал, может иная комбинация.

select
 count(port) ports_count,
 count(case when abonent!='' then 1 else null end) abonents_count
from ports

Считает кол-во строк port и abonent, исключая null и пустую строку для abonent. Если null и пустая строка одно и тоже, то case не нужен.

1) в /proc обычно монтируют виртуальную файловую систему дающую доступ к различной информации и ресурсам, предоставляемым ядром.
2) можно, при наличии прав, смотрите устройства tty, или что-то вроде этого.
3) можете при наличии прав.
4) лимиты операционной системы и файловой системы не контролируют содержимое файлов. Но в зависимости от задачи, можно решить, например, с помощью pipe, или ротацией.

Как уже советовали git-flow (например от Винсента Дрейзена). У разработчиков есть право мержить в dev свои ветки, поэтому request не нужны (они хороши при запросах от удаленных разработчиков), из dev собираете и прогоняете тесты ежедневно (CI), затем из dev собираете релиз и кидаете его в master, это уже делает отдельный человек. На сервере (если речь про прод) git быть не должно, должен быть нормальный CD. И да, никаких доступов к боевым у разработчиков. В остальном верно описали.

Включите вывод ошибок или загляните в логи. У вас в 8 строке вывод, поэтому отправка заголовка и не работает.

Делаете коммит с описание что сделали, что недоделали, начинаете коммит строкой "WIP: " (это стандартное сокращение означает "work in progress", многие системы игнорируют коммиты с таким началом описания).
После того как продолжите работу и сделаете логически завершенный коммит, то сделайте rebase и уберите этот коммит из истории (разумеется, если ветка это позволяет).

""грязное" выковыривание данных", "невнятный клубок данных"

А если бы вы написали что передаете объект в метод, а в этом методе используется только 10% свойств переданного объекта, вам бы написали, что это абсолютно нормально. Хотя по-сути это тоже самое.
Имхо, если здесь проблема и есть, то не в самом способе, а в данных, которые передаете. Если это логически связанные данные, то вполне нормально. Если это разрозненные данные, например конфигурация, то лучше пусть разбором будет заниматься отдельная процедура.
50 элементов это, конечно, мелочи, но если все-равно не хочется постоянно делать новые копии, передавайте по ссылке.