Выбор делается исходя не из красивости звучания, а по тому, являются ли api.site.ru и site.ru физически одной инсталяцией приложения или двумя.
Если у двух доменов одна общая кодовая база, а отличается только логика на уровне роутинга запросов, то нет смысла заморачиваться с поддоменами.
Минусы поддоменов:
Отдельные поддомены - это отдельный запрос браузера к DNS. Это время.
Если всё ваше приложение работает на SSL (а вам придётся перейти на него, когда захотите в статистике Google Analytics видеть рефереров) - на поддомены вам надо будет отдельные сертификаты, или wildcard сертификат.
И если поддомены работают на SSL, то браузер сделает дополнительный хэндшейк для обмена ключами с каждым поддоменом.
Если управление поддоменами ручное и вам придётся хостинг поменять, то руками двигать устанете.
Почему к какого-нибудь сайта поддмены третьго-четвёртого уровня?
Потому что, может быть, у них сервера API дублируются географически для распределения нагрузки.
Можно сделать ping на каждый поддомен и убедиться - у них, скорее всего, будут разные IP.
Выбираются автоматически или иным способом исходя из местонахождения пользователя.
Адрес домена API на SEO почти не влияет. Почти - это потому что гуглобот считает время от обращение к серверу до момента отрисовки страницы целиком, включая загрузку стилей, шрифтов, скриптов JS, загрузку данных и рендеринг страницы в своём виртуальном браузере. Если учесть пункты выше, то на установку соединения и хэндшейки придётся потратить время. По косвенным признакам медленные сайты имеют больше позицию в поисковой выдаче, то есть дальше от первого места. А вот откуда данные на странице появились, гуглоботу начхать.
Но иногда приходится жертвовать скоростью на DNS resolve и SSL handshake, и делать поддомены, если требуется выдавать много данных за раз. Например, если на странице очень много картинок, то браузер будет пытаться загружать их одновременно. В браузере есть ограничение на количество конкурентных запросов на один домен, кажется = 6. То есть пока не загрузятся 6 картинок (site.ru/img/1.jpg, ...), javascript не сможет обратиться к к данным на том же домене site.ru/api.
Варианты:
1. вынести всю статику (стили, картинки, скрипты) на поддомен static.site.ru - пусть статика тупит в отдельных запросах; причём javascript и css должны загрузиться первыми
2. выделить для api поддомен api.site.ru
Я обычно делаю первый вариант, но всё зависит от нагрузки.
Пример: сайт
icons8.com, API работает на домене
api.icons8.com и является независимым приложением, статика отдаётся через maxcdn.icons8.com
В данном случае я ожидаю рост нагрузки и при необходимости количество серверов будет увеличено, нагрузку распределю путём балансировки в nginx, а имя у них останется одно api.icons8.com
Чтобы время на DNS resolve уменьшить, используем DNS Amazon - он вроде самый быстрый. Ну и MaxCDN тоже использует Amazon и в общем потеря почти не ощущается.
Замеры времени делали через утилиту
www.webpagetest.org - классный сервис, просто золото.
