GTRxShock

с фреймворками знакомься, можно с микро начать, slim или silex, а потом полноценный пробовать: laravel, symfony, yii.
на фронте vue или react, совместно с webpack.

Как я понял, единственная цель PhpStorm+Openserver это "заменить" устаревший локальный сервер PhpStorm на современный Openserver со всеми настройками, возможными дополнениями, дебагеррами и т.д.

Цель PhpStorm'a - предоставить IDE. Цель OpenServer'а - предоставить полноценную (до некоторой степени) среду разработки и выполнения PHP-скриптов/приложений/сайтов/etc. Помимо интерпретатора PHP, в OpenServer'е есть масса других модулей (программ), в зависимости от "комплектации": от различных баз данных, для всяких "офисов" и т.д. Это связано с тем, что в большинство проектов не ограничивается исключительно интерпретатором PHP, многим так же требуются различные БД, иногда хранилища (например, Redis или Memcached) и прочие инструменты.

PhpStorm пишет - configuration php.ini file does not exist. Но php.ini там разумеется есть.

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

Обычно, процесс выглядит следующим образом:
0. Указывать путь до интерпретатор PHP не всегда обязательно или необходимо, иногда без этого можно вполне обойтись
1. В папке, в которую установлен OpenServer, среди прочего, есть папка domains, в которой вы создаёте папку с будущим проектом (сайтом) и называете её, например, site1.local
2. (Пере)запускаете OpenServer, крайне желательно это делать с правами администратора, т.к. он будет вносить изменения в файл hosts системы, что бы сайт стал доступен по соотв. адресу (в данном примере, по адресу: site1.local)
2.1. Открыть проект так же можно через меню OpenServer'a: Мои сайты -> "Нужный сайт"

Что бы проект открывался в PhpStorm'е по соотв. ("правильному") адресу, вместо встроенного веб-сервера - я думаю, нужно изменить какие-то настройки проекта в PhpStorm (какие именно - сказать затрудняюсь, т.к. никогда не пользовался таким способом работы с проектом).

P.S. Для того, что бы отлаживать проект в разных браузерах, обычно используют различные BrowserSync'и, LiveReload'ы и т.п.

P.P.S. Если Вам нужен простой веб-сервер с поддержкой PHP, исключительно для разработки/отладки - такой сервер есть в самом PHP.

Не согласен с Денис Загаевский
Есть одна книга по Андроиду, которая обновляется 2-3 раза в год.
Это "The Busy Coder’s Guide to Android Development", есть платная подписка за $20 в год на все обновления
https://commonsware.com/Android/
Последняя версия на данный момент 8.12 от 13 июня 2018. Вполне свежая книга.

Следует начать с проектирования API. Возмите https://swagger.io/ и набросайте все, что нужно.
Swagger вам позволяет объединить роутинг, документацию и примеры вызовов в единое целое.
Кроме этого он позволяет сгенерировать заглушки для разных языков программирования и фреймворков.
В принципе вы можете найти значительное количество интеграций для разных фреймоворков.

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

В REST есть 6 принципов, прекрасно изложенных в Wiki. В REST нет ничего сложного и особенного. Это просто надстройка над стандартным протоколом HTTP. Именно поэтому нет никаких особенных уроков. Изучите работу HTTP и вы поймете как работает веб в целом и REST в частности.

По поводу отдельного сервера для API. Есть множество разных подходов. В последнее время все более актуальными становятся Serverless-приложения. Serverless архитектура идеально вписывается в REST. Но думаю для вас это пока рановато и сложновато. Слишком много для начала.

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

По поводу best practices есть очень хороший ресурс https://12factor.net/ru/
Он в целом применяется для всех приложений.

Запомните: первый блин всегда комом. Прочитайте все ресурсы, которые я привел для вас. В них много ссылок на другие, походите по ним, присмотритесь. Напишите первую версию API так, как вам кажется удобно. Постарайтесь применить практики из статей.
Вам нужен опыт и вы его не наберетесь, пока не сделаете что-то сами. Вы можете потратить год на чтение, но останетесь на том же месте, с которого начали. А другой человек напишет на коленке API за неделю, а потом перепишет его 20 раз за год и он вам расскажет в 10 раз больше, чем то, что вы изучили за год.
Дерзайте!

Попробуйте программировать лифты ;) https://play.elevatorsaga.com/

https://money.yandex.ru/catalogue/charity
https://money.yandex.ru/get?_openstat=template%3Bi...

Писали тут про лейку недавно https://leyka.te-st.ru/instruction/ сам лично не пробовал, там есть четыре шаблона https://leyka.te-st.ru/campaign/demo-kampaniya/ и отображение сколько собрано из скольки

крутилку объекта

Какого объекта? Вы имеете в виду 3d объект или Вам надо фотки проигрывать, делая имитацию 3d? Во втором случае любой слайдер подойдет. А в первом легковесный вариант Вы вряд ли найдете, наверное самое рабочее вот:
doc.babylonjs.com/extensions/the_babylon_viewer

https://www.blend4web.com/ru/ там есть сразу экспорт в html

Существует несколько способов борьбы.

Вектор усложнения доступа к информации

Информация отдается с сервера с постоянной меняющейся структурой. Например блоки меняются местами и CSS генерируется налету, причем классы собираются рандомной цепочкой и имеют абсолютно рандомные названия. Это может повлиять на SEO.
Если этого мало, то контент рендерится с помощью JS аналогичными алгоритмами. Сам JS тоже генерируется и обфусцируется. Доставка контента происходит через сложные технологии, например через WebRTC DataChannel или WebSockets. Про SEO не может быть и речи, плохо работает через мобильник.
С подобным подходом прийдется писать парсер под ваш сайт. Скорее всего он будет делать скриншот и скармливать его распознавалке.

Вектор контроля доступа к информации

Доступ к информации предоставляется определенному кругу лиц. Например клиентам. Объемы доступа регламентированы и превышение карается расторжением договора или штрафом.

Вектор ограничения доступа к информации с помощью каптчи

Для идентификации клиентов используются evercookie+fingerprinting. Используется рейтинг адресов и подсетей.
Для недоверенных подсетей (ip принадлежат в основном разного рода хостинг-провайдерам) captcha отображается сразу. Аналогично при появлении трафика из необычного места, например внезапный трафик из Индии или Китая.

Вектор "медленный сервер"

Анализируются поведенческие характеристики с помощью машинного обучения. Строится эталонная модель.
Все, кто не попадает под модель, упираются в медленный сервер. Сайт начинает отдавать контент сразу, но очень медленно, например страница может открываться секунд 30. Причем попытка параллельного запроса приводит к ошибке. Если сайт велик, то подобные штуки останавливают парсильщиков на ура. Вдобавок дополнительно контролируются определенные вещи, вроде "пользователь загрузил js и css", провел мышкой там и там.

Вектор для реального отваживания воришек

Кроме выше перечисленных способов, есть очень простые, но действенные способы. При обнаружении парсинга, парсильщику отдается неверная/искаженная определенным образом информация. Например, если есть подозрение на конкурента ворующего цены, можно отдать цены чуть выше настоящих и немного подменить название товара, например заменить определенным образом букву "а" на "a". Затем такая штука ищется поисковиком и находится сайт конкурента.
Далее вопрос решается так, как это удобно бизнесу. Обычно жалуются на нарушение копирайта. Ну или у конкурента внезапно сгорает склад. Тут уж кто на что горазд.

А это специально для любителей парсить чужие сайты: cломанные пальцы очень сильно мешают набирать на клавиатуре будьте осторожны, в большинстве случаев воровство контента того не стоит.

Подытожим. В большинстве случаев защита от парсинга вредит SEO.
Если у вас воруют контент, значит он хороший. Защищайте его с умом. Простые средства вроде копирайта и успешные дела за воровство контента отвадят воришек от вашего сайта. Просто придайте делам огласку. Отслеживайте воровство и жалуйтесь в поисковые системы.
Используйте технические средства для отслеживания воровства, например непечатаемые символы и стеганографию в картинках.
Используйте внутренние ссылки и привязки к контенту и его автору. Например логические отсылки на свои предыдущие работы или другие товары, которые можно купить только у вас.

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