Как мне их правильно соединить?Во первых - зачем? Смысл разноса api и приложения в том что бэк работает одинаково со всеми запросами (не особо важно кто и как их дергает, лишь бы права позволяли), а фронт не зависит от бэка в представлении. По этому фронт пишется как морда на каком-нибудь реакте, который от бэкенда получает данные по запросу. Нужно авторизоваться - стучишся в эндпоинт авторизации, отдаешь креденшелы, получаешь токен. Нужно список юзеров - берешь доку по апи, стучишся с нужным пэйлоадом на эндпоинт, получаешь жсон списка, из него рисуешь что хочешь...
Или frontend и backend размещены разными программами?что-то мне подсказывает что наверное вы рановато по знаниям взялись за задачу...
src="/static/img.png" и src="/templates/img.png"
И заметила, что основная часть задач - инфраструктурная.Такой работы всегда много, но есть нюансы.
Настройка тестовДа, это в любой разработке будет, не только во фронте
CI/CDСомнительно, но окэй, знать это очень желательно, но в крупных проектах этим занимается девопс, как минимум настраивает скрипты. В малых компаниях это раскидывается на разрабов, есть такая практика.
OLAP CUBE, оптимизация запросов к БД.А это вообще чисто бэкендерские заморочки, конечно никто бить за понимание таких штук не будет, но в целом фронту это не особо важно, у него должно быть расписано апи/эндпоинты и чего туда пихать и что получать. Уж оптимизацией запросов чистый фронтендер точно не обязан заниматься.
Насколько известно, REST не хранит состояние клиента между запросам.Это не значит что он вообще не хранит состояние клиента, это значит что он хранит только состояние на момент синхронизации, а МЕЖУ запросами состояние клиента находится в неопределенном состоянии до момента следующей синхронизации. То есть это не принцип который надо соблюдать, а констатация факта. Кроме того, в вашем примере бэкенду/апи вообще должно быть фиолетово на состояние клиента.
Клиент передаёт необходимые данные в первом запросе. Эти данные меняют состояние сущности (лабиринт) на сервере.Сущность лабиринт НИКАК не затрагивается, у вас может изменяться только принадлежащие вам сущности, в данном примере у вас будет меняться состояние робота.
Если бы клиент располагал всеми данными,то он был бы бэкендом и апи было бы не нужно. Собственно апи - способ обмена запрашиваемыми данными.
Последующие запрос-ответы связаны с предыдущими, не имеют смысла без выполнения предыдущих, поскольку сервер хранит изменяемую сущность (лабиринт).Не лабиринт.
Как серию "запрос-ответ" логически объединить?Зависит. Так как вопрос у вас на пальцах и вообще без конкретики, то и ответ будет достаточно общим в рамках описанной системы.
GET someapi.tld/api/v1/robot/{id}, в результате назад вы получите объект робота с координатами. Что с ними делать зависит от вашего функционала, например можно задать новые целевые координаты.
if(!$_GET["request"] || typeof $_GET["request"] !== 'string')typeof здесь не в тему, так как у вас ВСЕГДА приходит стринг, в гет запросе (как впрочем и в любом другом) нельзя указать тип.
1. Есть ли лучшие идеи, чем мои?В принципе идея не нова, есть даже сервисы готовые под похожие задачи, типа cors-anywhere от heroku и еще куча по запросу cors proxy.
Я понимаю, что можно напрямую делать запрос к '/?request=''" и не заморачиваться с .htaccess, но такой вариант не красив.Это вообще 2 разные задачи. .htaccess настраивается на единую точку входа как написал Сергей delphinpro, далее вы в коде все запросы прошедшие к индексу проверяете на $_SERVER['REQUEST_URI'] (никакой /?request вам не нужен), вытаскиваете из него урл картинки и уже например curl используете для получения ее с другого сайта. Картинку запросу отдать как текст, предварительно отослав соответствующие картинке заголовки.
2. Как лучше всего обработать ошибку и сделать перенаправление при ненужном или неправильном запросе?проверять $_SERVER['REQUEST_URI'] на "правильность", например что запрашивается файл определенных заранее типов, ака вайтлист. В случае несовпадения можно тупо отправить 404.
3. Как обеспечить безопасность субдомена?Безопасность от чего?
if(!file_exists(folder)) { // проверка на существование папки / файла (так папки или файла?)
CreateFolder(folder, req) //а если это файл, все равно создаем папку с таким именем?
return //то есть вложенность больше 1 уровня папки создаваться не будут?
}1. когда вообще в базе надо создавать отдельного пользователя? Есть практики что что почитать?Когда человек регистрируется в системе, вроде очевидно.
2. есть ли какие паттерны проектирования баз под такое. Идея-то интересная.Есть конечно. Только подход с пользователями бд обычно тупая идея, так как смена роли/группы/доступа будет нуждаться в прямом вмешательстве в систему бд, что не есть гуд. Обычно RBAC не реализуется на уровне пользователей бд, а использует код, который ориентируется на данные из бд.
3. Какие слова вообще гуглить?RBAC <ваш фреймворк> library
Есть ли смысл начать с устаревшего материала?4-5 лет не сказать что сильно устаревшие. ИМХО спокойно можно учиться, основы будут одинаковы для любой версии языка, изменения в новых версиях большей частью касаются ООП составляющей, до которой еще дойти нужно. В целом и ООП код более старых версий совместим с последними версиями, во всяком случае с 5+, в обратную сторону конечно же работать не будет. Ну а новые фишки по типу тайпхинтинга и анонимных объектов можно доучить и самостоятельно.
разработчики все время советуют перейти на новые технологии а если точнее на Laravel и с MySQL на PostgreSQL чтоб сайт не только стал современным но и работал шустрее.Переход с самописа на лару - хороший шаг, переход на постгрес нужен только если нужны конкретные задачи, решаемые постгресом лучше чем мускулем. Например, если у вас есть большой массив json данных, хранимых в соответствующих полях и требующий каких-либо выборок на основании этих полей, то есть по сути - если у вас база хранит ненормализованные сортируемые данные. В остальном выгода от перехода с мускуля на постгрес будет не видна без микроскопа.