Обслуживание REST API и статического контента из разных портов с помощью Spring Boot

Question

Можно ли обслуживать REST API и статический контент из разных портов с помощью Spring Boot? Это становится интересным при использовании CORS. Значит, подключенный nginx будет направлять запросы api.example.com к одному порту и запросы к static.example.com в другой порт. Пример:

GET :8080/index.html должен служить src/main/resources/static/index.html
GET :8090/customers/1 должен обслуживать контент, предоставленный (например) CustomerController

Запросы с переставленными номерами портов (8080 для REST API, 8090 для статического содержимого) не должны работать.

Ответ 1-го уровня: как сделать это с помощью встроенного Tomcat?
Ответ уровня 2: Как этого добиться с помощью управляемого Tomcat, в котором запускается Spring Boot Application?

Не решение, потому что это очевидно: "Разделите его на два приложения".

Answer 1

"Как сделать это с помощью встроенного Tomcat?"

Это может быть возможно, но не рекомендуется. Это вызовет у вас слишком много стресса, чтобы стоить того.

Вместо этого используйте префикс "/api/v1/" и разместите все ваши конечные точки отдыха за этим путем.

Путь "/ api" может затем специально управляться пружинной безопасностью (с учетом CORS и т. Д.).

Путь "v1" позволяет вам создавать версии API для ваших клиентов или для случаев, когда у вас может быть бизнес-логика, зависящая от даты.

"Как сделать это с помощью управляемого Tomcat, в котором запускается приложение Spring Boot?"

Я понимаю, почему ты это сделал; У меня были "люди"(?), Которые просили меня делать странные вещи, как например /

Я рекомендую такой же подход "/ api" для остальных конечных точек в этом сценарии, но блокирую все запросы к Tomcat для статического содержимого. Spring Security можно настроить таким образом, чтобы через tomcat можно было запрашивать только конечные точки отдыха в "api" и блокировать любой запрос к Tomcat на статическое содержимое.

Сконфигурируйте Nginx, чтобы он находился на том же сервере, что и tomcat, и настройте базу документов NgineX там, где будет статический контент после расширения войны.

НЕ создавайте этот каталог нигде внутри "META-INF" или "WEB-INF"; файлы в этих каталогах должны обслуживаться только Tomcat, и делать что-либо еще будет небезопасно.

Кроме того, не используйте Nginx для перенаправления на Tomcat, чтобы Tomcat передавал статический контент Nginx, который передает его клиенту. Если Tomcat собирается сделать что-то кроме простого извлечения контента из войны, тогда иметь Nginx - это лишнее.

Конечным результатом является то, что Nginx работает на другом порту, и кажется, что у вас есть два приложения, но на самом деле это не так.

Это не так хорошо, как просто держать свое угловое приложение отдельно, но вы знаете... "людей".

Если вы собираетесь использовать tomcat для обслуживания статического контента из файла war, не помещайте его в "src / main / resources / static /". Статический каталог хорош для развертываний jar, но он проблематичен при развертывании контента с войны. Вместо этого имейте это под "src / main / webapp /". Вам необходимо убедиться, что Spring Security все еще разрешает это, но стандартный tomcat разрешает все запросы на контент, который не находится в разделе "META-INF" или "WEB-INF".

И если все это по-прежнему не так, как нужно, то вы можете определить отдельный хост и соединитель в tomcats "server.xml" и определить два разных контекста с их собственной "docbase" в context.xml.

Контекстные документы: https://tomcat.apache.org/tomcat-8.5-doc/config/context.html

Документы хоста: https://tomcat.apache.org/tomcat-8.5-doc/config/host.html

Answer 2

Не уверен, как это сделать с Spring, но вы можете использовать Camel, который интегрирован в Spring. Я должен сказать, хотя это просто кажется, что это плохая идея. Было бы лучше иметь другой сервер для обслуживания статического контента и создавать прокси-серверы по мере необходимости. Но в любом случае все, что вам нужно сделать, это создать верблюжий маршрут, а затем либо перенаправить его обратно в мир Spring, либо просто доставить свой контент из верблюда. Вы можете привязать верблюжьи маршруты к другому порту. Кто-то в значительной степени задал здесь один и тот же вопрос: как запустить @RestController на другом порту? и кто-то еще предположил, что Spring Actutator может быть вариантом.