Михаил

Проще простого:
1. Регистрация выполняется через капчу
2. Ключ приходит через SMS или E-MAIL
3. При запросах - используется hash-подпись для проверки на стороне сервера.
Подробнее - здесь.

Вы не указали, для каких целей пишете API, а от этого многое зависит.

API используется как правило, для взаимодействия сервер-сервер. И тогда у вас нет view уровня.
Капча это view уровень, он не должен иметь отношения к API сервису.
При таком взаимодействии сразу исчезают проблемы с CRSF и iFrame.

CRSF - это только безопастность уровня браузер.

Я один такой помню главные элементы верстки прошлого?

<br>       <!-- отступ вниз -->
&nbsp;   <!-- отступ вправо -->
<img src="/pixel.gif" width="10" height="1"> <!-- прозрачный пиксель -->
<center>...</center>
<marquee>...</marquee>
<font color="..." size="...">...</font>

Хорошие разработчики постоянно развиваются и никогда не стоят на месте. Любое развитие состоит в делании дел, в решении конкретных задач и в обратной связи, которую ты получаешь от других или в результате рефлексии.

TL;DR: Читайте книжки, делайте дела, читайте чужой код.

Что можно начать делать прямо сейчас, чтобы стать программистом лучше?

1. Изучайте базу. Алгоритмы, сети, криптографию, архитектуру, ос, устройство браузеров, компиляторы и т.д. Изучение подобных вещей дает понимание какие задачи бывают в реальном мире и как "большие дядьки" решают возникающие проблемы. Это кладезь инсайтов.

2. Устройтесь на фултайм-работу с сильной командой даже если джуниором. Я считаю, что есть только один способ расти как разработчик: работать фултайм над одним бизнес-продуктом. Такой подход учит решать проблемы масштабируемости, думать заранее, работать над процессом, которому вы следуете в разработке, решать задачи, возникающие с длительной эксплуатацией, решать проблемы с удобными окружениями и вообще учиться планировать свою работу в связи с нуждами бизнеса.

3. Написание кода - не самая большая часть работы сеньор-девелоперов, я бы сказал. Но когда речь заходит о самом коде, нужно понимать что ты пишешь и зачем. Есть классические книжки, которые можно найти, например, в матрице компетентности программиста, есть современные, но полезные типа The Art of Readable Code, которую я очень рекомендую. Нужно читать книжки. На собеседовании я всегда спрашиваю какие книжки читал или читает соискатель и если ответ отрицательный, то это большой минус.

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

5. Наберитесь терпения. Это не случится за один день. Думайте над именованием, разделяйте обязанности, изучайте алгоритмы и экосистему, оптимизируйте ваше рабочее место, изучайте новые технологии, читайте статьи и в течение ближайших лет регулярных усилий вы обретете новый способ мышления и будете разрабатывать поддерживаемое и надежное ПО. Легкого пути, к сожалению, нет.

Angular 1 брать не стоит, т.к. имеет известные проблемы с производительностью при малом опыте работы в нем.
Angular 2 требует понимания и правильного подхода к использованию. Но это готовый framework. Выучил, осознал и работаешь.
React это библиотека по работе с DOM. Тут можно быстро начать освоив документацию и jsx. Но если данных много и сложная логика, то без сторонних библиотек типа Redux не обойтись.

Я для себя взял Angular 2.

// ...Controller/ProductController.php

class ProductController extends Controller
{
  private $service;

  public function __construct(ServiceInterface $serviceInterface)
  {
    $this->service = $sserviceInterface;
  }
}

// Bundle/.../Service.php

class Service extends ServiceInterface
{
  ...
}

// src/.../Resources/config/service.yml
services:

  ...
  
  controller.product:
    class: Bundle/Controller/ProdcutController
    arguments: ["@service"]

  bundle.service:
    class: Bundle/Service
    arguments: ["@other_service", "@another_service"]

  bundle.another_service:
    class: AnotherService
    argum....
  ...

ИМХО обращение к сервисам через $this->get('bundle.service') не очень хороший вариант...
или используйте то что предложил shaqster

Используйте namespace. Это достаточно распространенная практика для изоляции стилей.

Довольно просто, хорошо знать - значит знать ЧТО гуглить, чтобы решить проблему. Учить его - да что за дичь? он устареет через год, потом будет еще стопицот других, еще моднее.

это значит, что когда тебе сказали запили фичу, то ты не сидишь ломая голову и изучая чужие примеры, пиля костыли, спрашивая на этом форуме, а делаешь сам зная какие модули надо использовать и как, знаешь мануал на столько, что тебе не нужны подсказки вроде "а как мне сделать такую-то шнягу?", ты просто знаешь, что её можно сделать так и так двумя-тремя способами, надо только глянуть на страницу мануала подсмотреть синтаксис функций.