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

Ответ 1

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

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

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

Конечно, есть оговорки, но, вообще говоря, если вы не требуете поведения привязки модели MVC, ваша служба ориентирована на данные, а операции ориентированы на данные (например, операции CRUD), тогда вы, вероятно, Web API Controller 'вместо "Model-View Controller". И наоборот, если ваши операции ориентированы на View-centric (например, доставляют пользователю пользовательскую страницу пользователю), или вам требуется MVC Model Binding для генерации "ajax partials" (очень маловероятно), тогда вам понадобится MVC-контроллер.

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

Ответ 2

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

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

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

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

Ответ 3

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

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

• GET: Прочитайте
• POST: Создать
• PUT: Обновить
• УДАЛИТЬ: Удалить

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

Ответ 4

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

domain.com/api/area1/controller1/

domain.com/api/area2/controller1/

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

Ответ 5

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

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

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

Ответ 6

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

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

Например:

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

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