Alex P.

Пользуюсь BrowserStack, доволен.
Но я казуальщик :)

https://lumen.laravel.com/

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

Только никому не рассказывайте))))
тыць
еще раз тыць

Вам нужна помощь того, кто работает в компании, в которой все процессы выстроены грамотно и не просто работает, но и участвует в выстраивании этих самых процессов.

Из быстрых советов.

1. Завести систему управления проектами, лучше Jira пока ничего не придумали. Для разработчиков не самая удобная система, но с точки зрения бизнес процессов лучше ничего нет.

2. Разобраться с ролями, которые есть в аутсортинговых компаниях и внедрить их у себя. На данном этапе у Вас есть аккаунт менеджеры (Ваши переводчики) и разработчики. Нужны еще как минимум менеджеры проектов и менеджеры команд. В зависимости от скила и ответсвенности разработчиков определяется насколько горячо нужен отдел QA. На небольших проектах иногда и разработчики могут проверять свой код, QA отдел нужен, но может быть не первостепенной Ващей задачей.

3. Выстроить процесс разработки. Канбан или скрам, в зависимости от проекта. И четкое флоу задачи.
Получили требовния -> кто-то должен их прояснить -> кто-то должен сформировать пак задач, определить сроки и приоритет -> разработчики получают и делают задачи -> кто-то ревьювит код разработчика -> готовое решение заливается на тестовый сервер (или делается тестовый билд) -> разработчик первым проверяет свое решение -> QA отдел проверяет решение -> результат выкатывается на прод и клиент информируется о готовности

4. Если еть инициативные разработчики, можно сформировать команду которая будет выстраивать эти процессы. Например встречаться раз в пару недель и обсуждать, чтобы хотелось изменить/ улучшить. К таким решениям будет больше доверия.

Работа по выстраиванию процессов медленная и тяжелая, нужно определить приоритеты и составить план действий.

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

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

Попробуй Flux.

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