Когда нужен MVC, а когда API?

Знаю 2 сайта: у одного архитектура rest api, у другого mvc. Мне сказали что у того проекта который на mvc - там нет api. Ищу теорию в интернете и не могу понять как так. Сам в веб разработке новичок. В вакансиях вижу много что пишут про api (рестовое, но не суть) а про mvc мало, раз в 8-10 меньше. Здесь хотел бы понять когда надо применять api, а когда mvc.

Дополнительно:

одно другому не мешает
1. ты можешь иметь своё апи и общаться с ним со своего фронта
2. у тебя может быть монолит без апи
3. у тебя может бвть монолит и апи, с которым общаются твои клиенты
3. у тебя может быть апи, с которым общаешься ты со своего фронта и твои клиенты
но это очень поверхностно

API есть у любой программы. MVC это способ организации кода, наличия API он не исключает. Не стоит сравнивать тёплое с мягким.

• Будьте добры, подскажите, а что вы имели ввиду когда написали API есть у любой программы?
  Другие отвечающие написали противоположные вещи. Владислав: "2. у тебя может быть монолит без апи". Из ответа YepBro можно сделать вывод что api и mvc противопоставляются друг другу.
• gabana, API - Application Programming Interface, то есть способ взаимодействия с программой. Он есть у прошивок, драйверов, консольных программ, десктопных программ, сетевых программ, web-сайтов/web-сервисов/web-приложений, у всего. Если с вашей программой как-либо можно взаимодействовать, то у неё очевидно есть программный интерфейс. Многие сейчас ошибочно сводят API к наличию у web-приложения REST-интерфейса. Это ограниченный взгляд, с ним надо бороться. Особенно в разрезе того, что и программа с REST-интерфейсом может быть написана по принципам MVC.
• Сергей Горностаев, спасибо

Понятно же, что человек просто использует термины не по назначению. А имеет в виду способ взаимодействия с клиентом.
Словом "mvc" он называет классический способ, при котором сервер отдает клиенту HTML (а не JSON).
А словом "api" - REST сервис, при котором сервер отдает клиенту как раз JSON.

И суть вопроса сводится именно к различию между этими двумя способами:
- когда сервер генерирует HTML на основе полученных из БД данных, и отдает его браузеру
- или когда в браузере выполняется программа на JS, которая запрашивает с сервера только данные, а потом на их основе генерирует HTML

Поскольку первый способ является, условно говоря, "классическим", то про него в вакансиях и не пишут особо. А второй, поскольку является относительно "новым", и требует наличия пары несложных скиллов в дополнение к классическому, его оговаривают отдельно.

При этом с точки зрения бэкенд программиста разницы принципиальной между этими способами нет.
Главное в программе - это её бизнес-логика. И уметь надо в первую очередь писать её.
А в каком формате отдавать данные в браузер - дело десятое. И выбирать между "mvc HTML" и "api REST" нет смысла - уметь надо и то и то.

Ну и, как уже объяснили, MVC - это совсем другое. Архитектура приложения. Причем она используется для любых приложений, независимо от типа отдаваемых данных. M и C в "api" приложениях используются в полный рост. Только V немного упрощается. при этом поскольку MVC подразумевается по умолчанию, то и писать её в вакансиях тоже особого смысла нет.

• спасибо
• Я бы ещё добавил для новичка, что помимо MVC в . NET ещё есть другой (более свежий) паттерн - Razor Pages. Если хочется срезать углы, возможно стоит лишь поверхностно пробежаться по MVC для общего развития, т.к. Razor, на мой взгляд, удобней и лишён некоторых недостатков MVC.
• UniverseElement, ахаха, в . NET добавили возможность говнокодить по пхпешному ))))
• По сути тот же MVC, только не разбросанный по всему проекту в разных папках, а собранный в одном месте с возможностью быстрого переключения между view, view model и controller, что ОЧЕНЬ удобно.

Ответы:

API нужен, когда ожидается взаимодействие с другими сайтами и программами. Да хоть с Ведроид-прогой. В нагрузку можно сделать клиентскую часть полностью на JS, чтобы меньше повторяться — тогда это и будет ваш «сайт на API».

MVC (применительно к вебу) — это хотите сделать рендеринг всего вывода на сервере и делите вывод на слои: этот отвечает за подготовку информации, а этот — за её вывод в HTML.

• А что вы имеете ввиду под "В нагрузку можно сделать клиентскую часть полностью на JS, чтобы меньше повторяться — тогда это и будет ваш «сайт на API»." ? Что значит в нагрузку? Клиентская часть же и так включает в себя JS - какие-нибудь слайдеру, модалки, анимации... все это есть на каждом сайте
• «Полностью на JS» — это значит, передача HTML с сервера на клиент минимальна. JS-клиент обращается к API, получает JSON и генерирует страницу.

• MVC (применительно к вебу) — это хотите сделать рендеринг всего вывода на сервере и делите вывод на слои: этот отвечает за подготовку информации, а этот — за её вывод в HTML.

  получается если я пишу апи, то мвц мне не светит? Вотэтоповорот...

• ThunderCat, Не в том дело, что не светит.

  Можно сайт на MVC, но показать наружу и API — так надёжнее вообще-то, но и то, и другое надо отдельно тестировать. Работа основного сайта не говорит о корректности API, и наоборот. Потому и написал «чтобы меньше повторяться».

  Можно сделать какие-то куски сайта на API, какие-то на MVC. Пример: пост на MVC, комментарии на API.

  Можно сделать два уровня: сервер 1 выдаёт API, сервер 2 использует его результат и как-то выдаёт HTML (я бы не назвал эту технологию MVC, но очень похоже) — технология крайне редкая и обычно используется для нестандартных мест, где либо СУБД сделает больше связок, чем собственно данных (обычно что-то связанное с анализом рядов данных), либо просто есть движок на другом ЯП.

• ThunderCat, Либо если сервер 1 и сервер 2 в разном владении. Но тогда они ещё и географически далеко, серверу 2 приходится пользоваться каким-нибудь кэшем, и в результате получается что-то более близкое к MVC.
• ThunderCat, Что значит «надёжнее»: JS-клиент — это всегда AJAX. Головняк для разработчика, головняк для юзверя с ненадёжным соединением.
• Mercury13, проблема в том, что вы, как и автор вопроса, вообще не понимаете, что такое MVC.
  А в остальном всё верно
• Ипатьев, В настольном софте MVC более яркий, потому что веб живёт в моменте — в том моменте, который зафиксировал изолятор транзакций СУБД. Скрипт передаёт данные на момент T и заканчивает работу. Так что в вебе иногда (!) делят этот самый скрипт на два слоя: подготовку данных и генерацию видимого HTML. Что такое controller — среди разработчиков нет консенсуса.
• есть