RestAPI для веб-приложения на PHP или познаем дзен в чистоте

Однако мой код позволяет любому начинающему программисту, за минимальное время, развернуть свое API для мобильного или веб-приложения

Хорошо, но почему не используете пространства имен, psr? Уже 2016 год. Если бы дело происходило до появления всего этого — то да, было бы познавательно. А psr приучит писать новичков понятный для остальных код. Ладно, пусть он один работает, даже так — через полгода глянет и ужаснется всему этому.

Скажите, сколько джуниоров способны моментально интерпретировать современные лучшие практики в рабочий не забагованный проект?

Моментально мало кто сможет, потому и надо приучать не только писать свое, но и читать код библиотек, фреймворков и т.п. польза приведенного Вами кода — максимум показать идею, но не применять это в продакшне.

Да и скажите — сколько будут стоить услуги человека, который знаком с этими лучшими практиками не по наслышке.

Дешевле, чем выйдет исправлять баги после проекта, реализованного новичком. Да, обучаться нужно, но чтоб подобное не попадало в боевой проект нужен code review.

Я сам не люблю компромиссы, однако, особенно в кризис, я думаю — это уместно.

Скупой платит дважды — отдав такое новичку, придется после доплачивать за исправление возможных багов. Или когда настанет момент расширить немного функционал — стоимость возрастет, и с ростом проекта кто-то глянет, плюнет и напишет с нуля — выйдет быстрее, чем поддерживать подобное.
А если мыслить ближе к реальности — нечего джуниора к проектированию API подпускать, если только что-то очень-очень простое дать.

в течении пары часов можно прочитать статью "Пишем RestAPI на Slim/Silex/Yii2/Phalcon" итд, в которой вам покажут, что апи поднять можно в течении получаса, предложат хорошое структурирование кода и кодстайл по ПСР, а в конце дадут ссылочку на репозиторий на гитхабе с готовым кодом, чтобы вы тут же развернулись локально.

Скажите, сколько джуниоров способны моментально интерпретировать современные лучшие практики в рабочий не забагованный проект?

Смотря кого мы называем джуниором. По хорошему это должен быть чувак, который уже знает основы CS и может спокойно без какой либо помощи на каком-либо фреймворке решать типовые задачи.
Тут еще момент… большинство разработчиков-самоучек как-то не сильно пытаются понимать зачем придумали ту или иную штуку. Взять тот же ваш метод orm — вы ясно просто где-то слышали что ORM это для работы с базой данных но понятия не имеете что это такое. Другие же люди путают active record и orm, третьи считают что doctrine это data mapper и не замечают что там помимо этого еще куча всего (orm + unit-of-work + repository + entity manager).

любому начинающему программисту, за минимальное время, развернуть свое API для мобильного или веб-приложения.

Нечего "начинающим программистам" делать в коммерческой разработке. Пусть для начала поучатся.

Притом, он будет наглядно понимать что и как в нем работает.

Нет не будет. Он либо будет подражать фреймворкам, либо не будет замечать важных вещей потому что каждый день приходится возиться и допиливать свое детище.

Да и скажите — сколько будут стоить услуги человека, который знаком с этими лучшими практиками не по наслышке.

Если мы про рейт — то дорого конечно. А если мы про сроки разработки и риски — то дешевле чем джуниор. Намного практичнее взять одного-двух синьеров которые запилят MVP за пару месяцев и потом уже расширять команду джунами/мидлами, чем брать джуниоров, которые за те же пару месяцев напишут MVP, которое потом проще переписать чем расширять новым функционалом.

В итоге — очень полезный для малого бизнеса инструмент позволяющий проверить гипотезу в течении суток.

Silex, Lumen, Slim… Для этого всего есть микрофреймворки. Для чуть более зрелого прототипирования — Symfony 2.8 имеет возможность использовать фичу под названием micro-kernel, где отключено все лишнее. Да и инструменты типа Doctrine хоть и обладают неимоверно высоким уровнем сложности (я реально мало проектов знаю на PHP которые могут сравниться по сложности с доктриной) — но об этой сложности знать не нужно разработчику, он просто накидывает бизнес объекты, логику взаимодействия, а база данных появляется сама по себе. Самое то для MVP. А уже потом можно заниматься оптимизациями и т.д.

Я сам не люблю компромиссы, однако, особенно в кризис, я думаю — это уместно.

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

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

Еще по поводу этого пункта… Как думаете, почему "начинающих врачей" до интернатуры к пациентам не разрешают прикасаться? Или почему надо хотя бы ПТУ окончить для многих других специальностей?
И почему-то именно в программировании, которое обычно связывают именно с интеллектом, люди почему-то думаю что можно прочитать статейку и методом тыка начать делать проекты за деньги. При этом… хоть мы жизнью и не рискуем (хотя отдельные люди, которые работают с микроконтроллерами и пишут софт для автомобилей например и жизнью других людей рискуют), мы обычно рискуем чужими деньгами.
На моей памяти много прикольных стартапов умерло именно потому, что разработчики накосячили и в итоге товый функционал добавлялся ужасно долго. Типа писать чатик на PHP 2-3 месяца (вместо пары недель на ноде) и из-за факапа в архитектуре держать его на серваке который бернит $2К в месяц. А деньги то вложены и их уже не вернуть. Я знаю людей которые настолько верили в свои проекты, что закладывали дома (не в СНГ разумеется) что бы оплатить разработку и маркетинг своего проекта.
А теперь задумайтесь. Вот пишите вы свои фреймворки и т.д. Вопервых ввести нового человека в команду будет теперь дорого. Во вторых уровень технического долга заоблачный. В третьих вместо того что бы фичи реализовывать вы пишите новый роутер, который завтра может уже не соответствовать требованиям бизнеса.

да половина кода http://php.net/manual/ru/function.spl-autoload-register.php велосипед автолодера. И у вас ошибка в приложение:

    function __construct() {
        try {
            include 'db.config.php';
            $this->_db->exec('SET NAMES utf8mb4');
        } catch (PDOException $e) {

        }
    }

вызов класса два раза

$db = new db();
// some code
$dbTest = new db();

Вызовит fatal error. И экскепшины плохо не обрабатывать. Ибо при возникновение ошибки вы даже не поймете где искать. Ну и @.

Вы бы лучше не спорили, а дали нам ссылочку на сайт, где этот велосипед используется…

$action = "../../etc/passwd\0";

Ну про чудеса вроде… === 'false' Вы уже выше упомянули, поэтому я решил не дублировать)

Настоящая жесть тут — это:

return expression ? true : false;

Если это вот эта "Студия". Мне страшно :( Правда у них в портфолио всего 4 проекта, но учитывая с кем они сотрудничают, мне страшно не за студию, а за эти компании. Надеюсь, что такое качество кода только у их директора и он не участвует в разработке. Пусть это будет так… Пожалуйста :)

Т.е. если что Avito не признает в вас своего подрядчика? Уверены, что в условиях сотрудничества нет пункта, согласно которому нельзя публично светить себя как субподрядчика? Ситуация вполне может быть серьезной. У коллег была ситуация, когда конечный заказчик (Москва) случайно узнал, что субподрядчик из региона. Несмотря на то, что проект был практически завершен и заказчика устраивал контракт был сразу разорван.

А, ладно, я дополню код, чтобы было понятно, что я имел ввиду:

if ($var === Null || $var === 'Null') {
    return Null;
}

Хотя, я считаю, что и без этого понятно было, о чём речь.

Я сразу после публикации этой статьи хотел своё мнение написать по коду. После того, как у меня комментарий по объёму добрался до объёма статьи, я его просто не стал публиковать. :)

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

А сам код из статьи в целом я не очень хочу обсуждать, потому что у меня есть более продуктивные занятия. С людьми, которых я могу контролировать, я работаю и объясняю, почему в коде лучше делать так или иначе. С писателями статей я не работаю и не критикую их код, потому что по большей части это будет как об стенку горох. В данном конкретном случае я вижу, что автор вообще не нацелен на то, чтобы из критики делать выводы. Так что, я считаю, что все, кто критикует код в данной статье, делают это лично для себя. :)

Опять же, я не совсем понимаю, для чего вы мне объясняете, что «break» никогда не выполнится? Вы по какой-то причине думаете, что я этого не заметил самостоятельно, так? (Если чем-то эти вопросы обидно прозвучали, я искренне извиняюсь — у меня не было мыслей обидеть.)