Использование WebAPI или MVC для возврата JSON в ASP.NET

Я создаю приложение ASP.NET MVC, в котором много клиентских скриптов, оно будет использовать JSON и jQuery для управления DOM.

Я понимаю, как Web API контроллера и MVC контроллер может вернуть JSON.

Учитывая мой сценарий, следует ли мне использовать контроллер веб-API или контроллер MVC ?

Контроллеры веб-API могут быть созданы и размещены в любом приложении ASP.NET, а не только в приложениях MVC. Таким образом, очевидной причиной создания веб-API является отсутствие у вас внешнего интерфейса MVC (например, классические веб-службы RESTful, размещенные вашей компанией / организацией).

Контроллеры MVC обычно полагаются на MVC Framework, если вы посмотрите на шаблоны по умолчанию и большую часть работы, выполняемой сообществом и вашими коллегами, вы заметите, что почти все контроллеры MVC реализованы с учетом представления.

Лично я использую контроллеры MVC, когда намереваюсь ответить с помощью View (), и я буду использовать веб-API для всего, что не зависит от конкретного представления.

Конечно, есть предостережения, но в целом, если вам не требуется поведение привязки модели для MVC, ваша служба ориентирована на данные, а операции - на основе данных (например, операции CRUD), тогда вам, вероятно, понадобится 'Контроллер веб-API 'вместо' Контроллер представления модели '. И наоборот, если ваши операции ориентированы на представление (например, доставляют пользователю страницу администратора) или вам требуется привязка модели MVC для генерации «частичных данных ajax» (что очень маловероятно), тогда вам потребуется контроллер MVC.

Лично я использую контроллеры веб-API для управления клиентами RESTful на основе JSON, я использую контроллеры MVC для обработки базовой маршрутизации браузера и доставки SPA.

WebAPI предназначен для создания API. Если вы хотите, чтобы кто-то мог использовать ваш API в XML, JSON и т. Д., Вы можете создать веб-api.

В вашем случае вам нужно только поговорить с клиентом в JSON.

Даже если ваш веб-сайт в основном основан на клиентском скрипте, вы все равно будете использовать контроллер ASP.NET MVC, верно? И поскольку вы, возможно, уже логически разделили свои контроллеры на основе сущностей, имеет смысл добавить в него эти методы обслуживания json, а не создавать другой класс специально для веб-API.

Поэтому для вашей конкретной ситуации (если я правильно понимаю) я бы остановился на контроллерах.

Ответ сводится к разделению задач, ускорению создания сервисов и использованию условностей, а не конфигурации.

Основная ответственность контроллеров - работать в качестве координатора между представлением и вашей моделью, но в то время как основная ответственность API - работа с данными. В случае с соглашениями API очень легко выполнять операции CRUD. Ниже показано соответствие между операцией CRUD и действиями HTTP.

• Читается
• POST: Создать
• PUT: Обновить
• УДАЛИТЬ: Удалить

Таким образом, с API вам не нужно создавать отдельные действия и приписывать их действиям HTTP.

Единственное, что меня беспокоит в отношении ApiController, это то, что он основан на сайте, а не в области. На одном сайте может быть только одна подпапка apicontroller, в которой вы можете назвать свои методы контроллера. Есть ситуации, когда вы можете захотеть дублировать имя контроллера в разных областях:

domain.com/api/area1/controller1/

domain.com/api/area2/controller1/

Я помню, что для этого есть несколько настроек кода, но по умолчанию это не работает.

Я согласен с ответом Шона Уилсона (верхний ответ), но не уверен, почему, поскольку я немного смущен и все еще пытаюсь понять следующее (возможно, неправильное) предчувствие -

• Используйте WebAPI Controller для доставки данных JSON клиенту, чтобы клиент мог обрабатывать манипуляции с представлением. Этот процесс НЕ требует представления, а скорее просто ответа на то, что называется методом (например, запрос javascript), чтобы клиент мог обрабатывать любые манипуляции на стороне клиента.
• Используйте контроллер MVC, когда вам нужно использовать данные для управления представлением во время или сразу после page_load (т.е. не для приложений SPA).

Видите ли, я просто не знаю, почему я здесь неправ, и меня смущает, потому что в последней строке ответа Шона говорится: «Я использую контроллеры MVC для обработки базовой маршрутизации браузера и доставки SPA». - возможно, я не совсем понимаю, что такое спокойный клиент, когда предполагал, что это может быть метод JavaScript, который получает ответ в форме JSON. это ближайший пост в Stackoverflow, который был удаленно связан с ответом на мой вопрос, поэтому я отвечаю на этот пост вместо того, чтобы, возможно, дублировать вопросы.

В этом случае я бы порекомендовал WebApi, поскольку он идеально подходит для передачи таких данных на основе запросов Javascript. Обычно я разрабатываю свои контроллеры WebApi так, чтобы они возвращали дружественный объект JSON, который затем можно было легко проанализировать с помощью моего Javascript.

Единственный реальный момент, когда вы захотите использовать действие на контроллере MVC для такого рода вещей, - это если вы хотите сгенерировать некоторый HTML и заменить сегменты вашей страницы вызовами Javascript.

Например:

У вас есть JQuery UI Datepicker, который при выборе генерирует список переключателей, которые представляют события в выбранный день.

В этом сценарии вы можете использовать WebApi для возврата некоторого количества JSON, а затем сгенерировать необходимый HTML с помощью Javascript, но, как правило, создание большого количества HTML с использованием Javascript - плохая практика. Было бы намного лучше, если C # создаст HTML, а затем вернет его через частичное представление, так как таким образом вы с меньшей вероятностью столкнетесь с ошибками при синтаксическом анализе Javascript. Не говоря уже о том, что это упрощает написание HTML.