Потому что в Америке принято продавать продукт, а не впаривать говно.
Именно поэтому принято, чтобы продукт говорил сам за себя.

Пользователю нафиг не нужен телефон, чтобы начать использовать продукт. В большинстве случаев нужен email, чтобы получить ссылку на авторизацию и начать работу с продуктом. В США большая часть населения умеет пользоваться Интернетом, компьютером и в состоянии ввести номер кредитки для оплаты продукта/услуги онлайн.
В России есть специфика - IT-имбецилы, которые не умеют пользоваться компьютером, поэтому им нужно звонить и говорить, на какую кнопку надо нажать и как оплатить. Аналогичная ситуация в Китае, у этих дебилов вообще практически везде авторизация завязана на номер телефона.

Есть еще один момент, телефонный звонок крайне навязчив, фактически посягательство на личное время и часто неуместен. Лично я провожу в некоторые дни до 60% своего времени на совещаниях. Мне некогда выслушивать и кому-то звонить. А вот email я могу быстренько просмотреть.

Вам не нужна форма захвата, вам нужно показать продукт и дать пользователю возможность им пользоваться. Если продукт нравится, то за него заплатят. Остальное все - шелуха.

Следует начать с проектирования 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 раз больше, чем то, что вы изучили за год.
Дерзайте!