У меня есть домен (назовем его one.com) это содержит:
Служба API используется мобильной платформой, которая вызывает ее через URL-адрес. one.com/api. Содержимое, которое поступает / выходит через API, является просто данными JSON.
Все размещено на известном сервисе, который гарантирует очень большую пропускную способность. В любом случае у нас никогда не было проблем с достижением лимита, так как объем передаваемых данных и использование приложения относительно низки.
По нескольким причинам мы решили переместить всю инфраструктуру БД и API в другой домен, назовем его two.com, с конечной точкой API two.com/api, оставив только сайт. Для этого запросы, которые мобильное приложение отправляет one.com/api должен быть перенаправлен на новый two.com/api. Мы успешно сделали это, используя способ Apache htaccess "mod_rewrite".
Теперь, когда щедрый хостинг для one.com стало слишком много для одного веб-сайта, мы собираемся перейти на более дешевый общий хостинг, но на этот раз мы читаем, что «приблизительная нагрузка в 10.000 посещений в месяц подходит для этого общего плана».
Очевидно, это справочная информация, и она должна подходить для нашего веб-сайта, но как насчет службы REST API? Я имею в виду, one.com на пропускную способность по-прежнему будут влиять звонки на one.com -> two.com запросов, представляющих возможное узкое место, если использование нашего приложения увеличится в будущем?
Я предполагаю, что вы говорите о редиректе 301 (перемещен навсегда).
Ваш сервер one.com по-прежнему будет использовать некоторую пропускную способность, но не так сильно, как до перенаправления. Редирект 301 просто отвечает клиенту заголовком ответа, говорящим ему вместо этого запросить новый URL. Он не отправляет фактическое содержание нового URL-адреса. Таким образом, вы будете использовать только минимальную полосу пропускания для отправки этого небольшого заголовка ответа, однако в зависимости от того, насколько популярен ваш api, он все равно может увеличиваться. Это также зависит от того, достаточно ли умно ваше приложение, чтобы понять, что 301 означает 301, а не 302, и не забыть отправлять будущие запросы на новый URL.
В любом случае было бы гораздо лучше обновить приложение, чтобы оно указывало на новый URL-адрес.