Полезная тема о слоях и слоях здесь :
С упрощенной физической точки зрения у нас есть клиент (браузер), сервер приложений, сервер БД.
С логической точки зрения у нас могут быть разные слои (опять упрощенно): сеть, бизнес-логика, данные.
Идея многоуровневого подхода заключается в том, чтобы сначала разделить задачи (представление, бизнес-логика, постоянство и т. Д.), А более высокий уровень может вызывать только непосредственный уровень ниже (поэтому в примере перед веб-уровнем можно вызывать только бизнес-логику, он не должен вызывать слой данных). Приятно то, что каждый уровень имеет интерфейс, который предоставляется без каких-либо подробностей реализации (шаблон кода для интерфейса), так что вы можете поменять местами реализацию уровня. Так что теперь вы можете хранить данные в реляционной БД, но вы можете создать новую реализацию, которая хранит данные в NoSql db (вам не нужно ничего менять на уровне бизнес-логики). Таким образом, у вас один и тот же уровень данных, но разные реализации.
В традиционном веб-приложении java код развертывается на сервере приложений, а его выход (сервлет) обычно представляет собой HTML-код, который отображается в браузере.
Таким образом, уровень представления (форматирование и т. Д.) Выполняется на стороне сервера для каждого клиента (запроса). Имея клиентов на сервере приложений, у нас есть сеанс, поэтому состояние для каждого клиента (например, отображаются языковые данные, соответствующий формат даты и т. Д.).
Архитектура REST вносит изменения, поскольку она поддерживает операции без сохранения состояния. Одним из последствий этого было перемещение любого кода, связанного с клиентом, в браузере (появление веб-фреймворков javascript) с переменными сеанса, а затем веб-слой возвращает JSON / XML вместо HTML.
Чтобы ответить на ваш вопрос, у вас может быть другой веб-слой поверх бизнес-логики. Можно вернуть HTML, можно вернуть JSON (подумайте об этом, как в примере со слоем данных).