Quber
@Quber
PHP Team lead

Какую структуру WEB API вы используете в своих проектах: api.site.ru или site.ru/api/?

1. Какую структуру WEB API вы используете в своих проектах?
2. Какой вариант вариант Вы считаете лучшим и почему?
3. Какой вариант лучше для SEO (если он лучше?)
4. Выделите из списка ниже наиболее предпочтительный вариант API для ссылки типа: moscow.site.ru/products/
api.moscow.site.ru/products/
api.site.ru/products/
moscow.site.ru/api/products/
site.ru/api/products/


UPD. api выполняет, не приложение, а сайт

Спасибо
  • Вопрос задан
  • 1123 просмотра
Пригласить эксперта
Ответы на вопрос 3
sofcase
@sofcase
Веб-разработчик
1. api.site.ru
2. Да просто так удобней.
3. Не влияет, вроде как
4. api.site.ru/products/ а вот moscow уже можно решить на уровне параметров или сессий

PS. Если необходимо использовать API на сайте, то в случае с api.site.ru можно просто делать проксирование с site.ru/api/ на api.site.ru
Ответ написан
copist
@copist
Empower people to give
Выбор делается исходя не из красивости звучания, а по тому, являются ли 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 - классный сервис, просто золото.
Ответ написан
Комментировать
@Ronii
Если API выполняет отдельное приложение, то можно в поддомен.
api.site.ru/products/moscow/
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы