Где место HTTP в паттернах MV*?

Можно, вообще говоря, считать, что в случае хттп мы имеем какой-то второй mv* паттерн вслед за первым. Для которой твоя модель станет уже вьюхой. И как у тебя был контроллер для вьюхи так же будет контроллер для этой модели (которая с другой стороны сама вьюха), он будет ловить события этой модели (например, как модель оповещает свою вьюху в mvc в случае активной модели, она так же может оповешать и этот контроллер) а сам контроллер как раз может передавать это событие в виде хттп запроса на твой бекенд. Как-то так.

Но это лишь один вариант организации.

Можно, вообще говоря, считать, что в случае хттп мы имеем какой-то второй mv* паттерн вслед за первым. Для которой твоя модель станет уже вьюхой

Спасибо. Хорошая аналогия Понятно, что это уже не MVC, но аналогия хорошая )

Куда мне засунуть http-запросы?

HTTP - это протокол передачи данных между программами клиента и сервера в среде WWW. Соответственно, http-запросы и ответы должны формироваться где-то на границах ответственности этих сущностей, смотрящих друг на друга.

А что с моделью? Одна модель на всё приложение или по модели на каждый View?

Смотря что за модель. Есть модель данных приложения. Есть модели данных состояний элементов управления (виджетов) и самого View. Если все данные засунуть в один объект модели, то это исключит «лишние» уровни абстракций, приведёт к запутанным потокам данных внутри приложения («быстро и грязно»), возможно улучшит быстродействие, но ухудшит дальнейшее сопровождение и понимание логики работы сторонними товарищами.

На вебе, особенно в браузере, как правило все укладывается в рамки одиночного выхлопа. Соответственно все изыскания тут.

Нотификации рассматриваются укрупненно сначала, далее может выясниться, что можно обойтись без них.

Как правило, выхлопы (теоретически) связаны (условно) со следующими паттернами: command, action, facade, CS, interpreter, decorator, factory, builder, bridge, chain, mediator, proxy, adapter, strategy, service locator, DI и т.д.