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

Question

[Quber]

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 выполняет, не приложение, а сайт

Спасибо

Comments

[Павел Волынцев]

вас устроили ответы на вопрос?

Answer 1

[Юрий Тарахонич]

1. api.site.ru
2. Да просто так удобней.
3. Не влияет, вроде как
4. api.site.ru/products/ а вот moscow уже можно решить на уровне параметров или сессий

PS. Если необходимо использовать API на сайте, то в случае с api.site.ru можно просто делать проксирование с site.ru/api/ на api.site.ru

Comments

[Quber]

Спасибо. Moscow используется для примера, имхо такой подход лучше для поисковиков (нежели хранение в сессии). Вместо Moscow может использоваться
electomics.site.ru
mebel.site.ru
plants.site.ru
и т.п. (так например у Викимарт сделано). Поэтому субдомен нужен.

[Юрий Тарахонич]

Quber: я может не познал дзен, но поисковикам все равно что у вас там в API, потому хранения moscow в сессии ни как не отразится :)

[Quber]

Юрий Тарахонич: мы о разном говорим. В данном случае, задача стоит использования api именно с именем города (в данном случае moscow) в составе url (либо пусть то будет products, mebel и т.п. не важно). Вопрос не в том как убрать moscow, а как его сохранить в составе web api в url. Думаю так понятно.

[Юрий Тарахонич]

Quber: тогда это можно решить проксированием. например:
site.ru/api => api.site.ru
*.site.ru/api => api.site.ru с передачей дополнительным параметром *

проксирование можно сделать стандартными средствами nginx.

Answer 2

[Павел Волынцев]

Выбор делается исходя не из красивости звучания, а по тому, являются ли 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 - классный сервис, просто золото.

Answer 3

[Ronii]

Если API выполняет отдельное приложение, то можно в поддомен.
api.site.ru/products/moscow/

Comments

[Quber]

api выполняет сайт