Это достаточно «классическая» задача в PHP — приём и отправка обычной формы. Давным-давно, ещё во времена PHP 4, в книгах приводился пример того как это делать. Это всегда был один php-файл, где размещался и обработчик формы, и html-код вывода формы, и вывод ошибок. Понятно, что на заре рождения PHP, говорить о каком-то разделении кода или даже о культуре программирования не приходится. Но, недавно я случайно наткнулся на книгу о PHP 7 2018 года выпуска, где рассказывается об основах языка, классах, есть даже глава о PostgreSQL и даже описано несколько ООП-шаблонов проектирования.

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

Чтобы продолжить, давайте определимся что именно неверно в таком подходе.

В продолжении предыдущей темы, что база программирования важнее самого языка, покажу на примере Turbo Pascal 7.0, что такое объекты в объектно-ориентированном программировании. (Чтобы было понятно, ООП в Паскале появился в 1989 году в версии TP 5.5.)

Если начинать изучать объекты, например с PHP, то не будет понимания, что это вообще такое. Зачем, например оператор new, что такое поля или методы? Такие вещи воспринимаются как часть языка, а всё что внутри — чёрный ящик, где происходят какие-то скрытые процессы. Вообще ООП — это парадигма, то есть описывает вроде как только общие принципы, а конкретная реализация зависит от языка. Но, на самом деле ООП в итоге всё равно превращается в обычный исполняемый код. На мой взгляд важно понимать откуда он берётся.

Тут ещё проблема в том, что изучение ООП обычно начинают с размусоливания про иерархию объектов на примере уточек, птичек и прочей живности. В итоге вместо технического описания, получается невероятная абстракция, которую нужно ещё как-то перенести в реальный код.

Для новичков, которые только задумываются об IT, вопрос выбора первого языка программирования (ЯП) стоит достаточно остро. И это понятно — ведь языков очень много, а критерии выбора не такие очевидные.

Эта тема, безусловно, холиварная, поскольку опытные программисты дают советы через призму собственного жизненного опыта. Масла в огонь подливают менеджеры и маркетологи многочисленных контор, которые занимаются обучением. Такие давно уже не стесняются давать объявления, где обещают сделать востребованным супер-пупер программиста за 1, 2, 3 (подставьте любое число) месяцев. В качестве первого языка предлагают что угодно, приводя в качестве аргументов некий рейтинг популярности или даже количество меток на StackOverflow.

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

Думаю, что каждый php-программист знаком с сессиями и может даже работал с ними. Сессии — это стандартный механизм PHP и применяется наверное во всех CMS или фреймворках в том или ином виде. Так же написаны сотни (если не больше) php-библиотек, которые предлагают множество функций для упрощения кода.

В целом же работа с сессиями очень простая и если говорить с практической точки зрения, то есть очень мало задач, которые стоят перед программистом. Первая — это добавление и получение данных в сессию, и вторая — организация flash-сессий для создания «мигающих сообщений». Очень часто это так и называется «flash message». Простой пример: после обновления данных, нужно вывести сообщение для пользователя только один раз.

REST — это концепция для взаимодействия компонентов основанный на протоколе HTTP. Не хочу останавливаться на скучной теории (вики в помощь), а дам простое объяснение применительно к сайтам.

В Сети обмен происходит по протоколу HTTP: запрос - ответ. Для того, чтобы передать какие-то данные, их нужно как-то идентифицировать, то есть указать их «признак», «действие» или что-то подобное. И поэтому раньше данные требовалось оформить в виде какого-то сложного формата, обычно это XML или Json.

Так вот, REST говорит что этого делать не нужно. Данные передаём как есть, только у HTTP-запроса указывается метод (параметр) для этих данных. Обычно мы оперируем GET и POST, поскольку они работают «из коробки» в HTML и их поддерживает любой браузер. Но на самом деле, метод у HTTP может быть абсолютно любым. Есть некие общепринятые: PUT, DELETE, OPTIONS, PATCH, но это совсем не стандарт.