Каков наилучший способ перенаправления URL-адреса при разработке на localhost?

Question

Проблема:

У меня есть два веб-приложений, и «App1» извлекает данные из «App2» через производство ajax.In, App1 должен извлекать данные из производства URL для App2. Однако, когда я разрабатываю App1 на localhost: 3000, я хочу, чтобы App1 получал данные из локальной версии App2 на localhost: 3001 (не из производственной версии).

Предыдущие исследования:

Я искал вокруг много для того, как сделать это, но не могу сделать головы или хвосты материала, который я нашел.

• Я прочитал некоторые вещи, предполагая, я должен изменить/и т.д./хосты, но я не смог получить, что работать, потому что сайт использует HTTPS производства, но мой локальный только HTTP.

• Я также сталкивался с файлом .htaccess, но добавление файла, похоже, не имело никакого эффекта, и я довольно теряюсь в кроличьей дыре Apache, просто ищу, как включить материал .htaccess. (Я тоже видел кое-что о mod-rewrite, но не могу понять, как это сделать.)

• Я также обнаружил расширения Chrome, такие как Switcheroo Redirector, но это не сработало потому что простые переадресации меняют некоторые важные HTTP-ответы на 301, которые мое приложение не предназначено для обработки.

Вопросы

• Что такое правильный инструмент для того, что я пытаюсь сделать? (/ etc/hosts, .htaccess или что-то еще)

• Какова самая базовая конфигурация этого инструмента для получения желаемого результата?

Answer 1

Обычно вы как-то хотите изменить URL-адрес, фактически запрошенный app1. Обычно такой URL (по крайней мере, базовый URL) является параметром конфигурации приложения, а не жестко закодированным. Таким образом, вы можете поместить его в файл конфигурации или, более элегантно, передать его как переменную окружения от http-сервера к скрипту php. Тогда, и только тогда у вас есть все средства переписывания, которые вы хотите. Но без этого запросы даже не дойдут до вашего локального http-сервера, что означает, что все попытки сделать что-либо просто не имеют никакого эффекта.

Другим вариантом, однако, является изменение конфигурации имени локального узла, чтобы разрешить это имя производственного процесса app2 на локальный IP-адрес. Затем вам придется настроить виртуальный хост внутри вашего локального http-сервера с именем производственных систем и включить https. Вы можете использовать самоподписанный сертификат для шифрования ssl. Это должно работать, только ваше приложение должно принять такой самоподписанный сертификат для соединений https, поэтому проверка сертификата должна быть отключена.

Answer 2

Я сделал бы простой запрос с jquery следующим образом.Посмотреть более подробную информацию о запросе запроса Ajax с запросом http://api.jquery.com/jquery.ajax/

var url = "localhost:3001/cart/1"; 
$.ajax({ 
      url: url, 
      data: currentQueryData, 
      success: function(data) { 
       console.log("Data from App2 url: + data); 
       // Do something with your data 
      }, 
      failure: function(error){ 
       console.log(error); 
      } 
     }); 

И когда вы идете с развитым Apps для производства просто изменить значение свойства URL в «https://api.app2.com» Так что запрос идет, чем к производству app2. Вы также можете указать производственные URLs для вашего локального хоста, отредактировав/и т.д./файл конфигурации хостов и добавьте в него:

127.0.0.1 domain.app2.de 

Но вам нужно еще добавить порт в этот домен в вашем файле JavaScript. Например:

var url = "domain.app2.de:3001" 

Поскольку вы не можете привязать домен к определенному порту в файле/etc/hosts. Так что что-то вроде следующего не работает!

127.0.0.1:3001 domain.app2.de # not working 

Надеюсь, это поможет. Я бы рекомендовал сохранить URL-адрес точки входа в приложение 2 в конфигурации. Чтобы сохранить его в значении javascript, просто для того, чтобы показать, как сделать это как пример siplefied. В противном случае было бы здорово, если бы вы могли привести пример, который вы хотите извлечь из приложения2.

Answer 3

Я бы использовал mod_proxy + mod_rewrite так, чтобы все URL-адреса с одним префиксом пути в основном домене переписывались внутренне в прокси-запрос к app2. Это имеет ряд преимуществ:

1. Вы не загрязняете свой интерфейс интерфейсом сервера. Это дает хорошее разделение проблем и гарантирует, что код не отличается между dev и live.
2. Отсутствие проблем с CORS, потому что для клиента все запросы отправляются по той же схеме, домену и порту.
3. URL-адреса Ajax более чистые, так как они могут быть просто относительными к корням. (Как и все ваши URL-адреса.)
4. Вы можете использовать тот же, немодифицированный файл на dev и live-серверах, потому что он может условно переписать каждый app2 на основе отправленного заголовка хоста. (Хотя вы действительно должны размещать конфиг в своем vhost, если у вас есть к нему доступ.)
5. Вы можете использовать ту же условную логику, чтобы обеспечить только https в реальном времени. (Не делайте этого в коде приложения.)
6. Вы можете переключиться на разные серверы приложений2 для переустановки/обновления, отредактировав одно правило без прерывания для пользователей.

Предполагая, что вы делаете это в .htaccess

RewriteEngine on 
# force https and single domain on live 
RewriteCond %{HTTP_HOST} !=localhost 
RewriteCond %{HTTP_HOST} ^(?!real-app1\.com$). [NC,OR] 
RewriteCond %{HTTPS} =off 
RewriteCond %{THE_REQUEST} ^\S+\s+/(\S*) 
RewriteRule^https://real-app1.com/%1 [NS,NE,L,R=301] 
# API proxy on dev 
RewriteCond %{HTTP_HOST} =localhost 
RewriteCond %{THE_REQUEST} ^\S+\s+/API(?:/(\S*))? 
RewriteRule ^API(?:$|/) http://localhost:3001/%1 [NS,NE,P] 
# API proxy on live (no need for hostname check) 
RewriteCond %{THE_REQUEST} ^\S+\s+/API(?:/(\S*))? 
RewriteRule ^API(?:$|/) https://real-app2.com/%1 [NS,NE,P] 

Затем, в переднем конце, нормальные ссылки могут быть просто <a href="/foo/bar/">… и, предполагая, что вы используете библиотеку AJAX, может быть столь же легко, как это :

$.ajax('/API/path/to/endpoint/', { 
    data: { 
     query_param: 'param_value' 
    } 
}) 
.done(function() { 
    // API works 
}) 
.fail(function() { 
    // oh dear 
}); 

Там, приложение2 должно получать http://localhost:3001/path/to/endpoint/?query_param=param_value. Объем работы по настройке правильной работы меньше, чем головная боль, связанная с управлением проблемами конфигурации и развертывания для жизни приложений. Определенно стоит того.